On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand wrote:
> > /tmp 8,0G 60M 8,0G1% /tmp
> > Does this count as "large files"?
> > As "a lot of small-only files"?
> >
> Exactly how is this a practical explanation and example? :/
> Are you saying that in *
Hi,
I generated a list of source packages which have been removed from
unstable, but are still kept into experimental for some reason. I
excluded those which seem maintained, and generated a dd-list of the
remaining ones. I will file removal bugs for them within the end of
June if nobody claims th
On Sat, May 26, 2012 at 12:09:53 +0200, Luca Falavigna wrote:
> Debian X Strike Force
>xserver-xorg-video-v4l
>
This should be kept around, and a newer version uploaded to unstable.
Cheers,
Julien
signature.asc
Description: Digital signature
On Fri, 25 May 2012 21:56:55 -0400
Ted Ts'o wrote:
>
> The major difference is that tmpfs pages only get written out to swap
> when the system is under memory pressure. In contrast, pages which
> are backed by a filesystem will start being written to disk after 30
> seconds _or_ if the system i
On Fri, 25 May 2012 15:12:03 -0400
Nikolaus Rath wrote:
> Weldon Goree writes:
> > If only ext*fs supported quotas...
>
> 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%.
Yes, but I was thinking of a multi-
2012/5/26 Clint Byrum:
> On laptops and other power sensitive devices, this is pretty critical.
> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).
> With a regular file
> Weldon Goree writes:
> On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:
>> I think having / and /tmp share the same file system is a bad idea,
>> because then writing lots of stuff to /tmp would potentially fill up
>> the root file system (that typically also includes /var) an
Package: general
Severity: minor
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome
On 05/26/2012 04:40 PM, Andrey Rahmatullin wrote:
> On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand wrote:
>
>>> /tmp 8,0G 60M 8,0G1% /tmp
>>> Does this count as "large files"?
>>> As "a lot of small-only files"?
>>>
>>>
>> Exactly how is th
On Sat, May 26, 2012 at 10:47:37PM +0800, Thomas Goirand wrote:
> >>> /tmp 8,0G 60M 8,0G1% /tmp
> >>> Does this count as "large files"?
> >>> As "a lot of small-only files"?
> >>>
> >>>
> >> Exactly how is this a practical explanation and example? :/
>
On 05/26/2012 01:33 PM, Clint Byrum wrote:
> On laptops and other power sensitive devices, this is pretty critical.
>
> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).
>
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia
I think that we should keep in mind that this is not about whether tmpfs
for /tmp is good or bad, or it gives a 3-second performance gain when
unpacking a tarball on /tmp, but about the sane default setting.
default settings are meant to be *sane* settings that prioritize
stability over performan
On 25/05/12 12:20, Henrique de Moraes Holschuh wrote:
> On Fri, 25 May 2012, Salvo Tomaselli wrote:
>>> Because paging out a couple Gigabytes is veery different from
>>> writing a couple Gigabytes to disk, of course.
>>
>> Yes because writing that on disk will only block the thread performing t
On 05/26/2012 11:14 PM, François Bottin wrote:
> On 05/26/2012 04:47 PM, Thomas Goirand wrote:
>> Try playing a 2h video with flash, and see that 60 MB isn't enough...
>
> If Adobe Flash is broken, then fix it!
>
>
I will let you ask the sources from Adobe, create an
alternative *that works*. I wil
Thomas Goirand writes:
> I will let you ask the sources from Adobe, create an alternative *that
> works*. I will also let you fix all the other apps that we mentioned
> that have the same kind of issues. But *IN THE MEAN WHILE*, until you
> are done with this huge and important work, let's not ch
On 26/05/12 19:13, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> I will let you ask the sources from Adobe, create an alternative *that
>> works*. I will also let you fix all the other apps that we mentioned
>> that have the same kind of issues. But *IN THE MEAN WHILE*, until you
>> are done
Carlos Alberto Lopez Perez writes:
> On 26/05/12 19:13, Russ Allbery wrote:
>> I find some of the assertions in this thread confusing. I've been
>> using tmpfs /tmp on my laptop for quite some time and have watched
>> hour-long movies via the Adobe Flash player and have never noticed any
>> unex
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
Package: wnpp
Severity: wishlist
Owner: "Yao Wei (魏銘廷)"
* Package name: gcin-table-dayi3
* URL : http://hyperrate.com/dir.php?eid=67
* License : Proprietary (Not modifiable)
Description : Dayi 3-key table for gcin input method
This is one of the Chinese input method
Package: wnpp
Severity: wishlist
Owner: Benjamin Eltzner
* Package name: qpdfview
Version : 0.2.2
Upstream Author : Adam Reichold
* URL : https://launchpad.net/qpdfview
* License : GPL-3
Programming Lang: C++
Description : tabbed PDF viewer
--
To
On 26/05/12 19:43, Russ Allbery wrote:
> Carlos Alberto Lopez Perez writes:
>> On 26/05/12 19:13, Russ Allbery wrote:
>
>>> I find some of the assertions in this thread confusing. I've been
>>> using tmpfs /tmp on my laptop for quite some time and have watched
>>> hour-long movies via the Adobe
On Sb, 26 mai 12, 21:29:30, Ivan Shmakov wrote:
>
> … But that makes me recall a solution to both the /tmp and quota
> issues I've seen somewhere: use ~/tmp/ instead of /tmp. This
> way, user's temporary files will be subject to exactly the same
> limits as all the other h
On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
> … But that makes me recall a solution to both the /tmp and quota
> issues I've seen somewhere: use ~/tmp/ instead of /tmp. This
> way, user's temporary files will be subject to exactly the same
> limits as all
Carlos Alberto Lopez Perez writes:
> On 26/05/12 19:43, Russ Allbery wrote:
>> Carlos Alberto Lopez Perez writes:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096
>> That bug contains little actual information, not even what software was
>> being used.
> Ok... so you want a prove?
On 05/26/2012 07:08 PM, Thomas Goirand wrote:
On 05/26/2012 11:14 PM, François Bottin wrote:
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
I will let you ask the sources from Adobe,
On 26/05/2012 20:32, Ted Ts'o wrote:
> On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
>> … But that makes me recall a solution to both the /tmp and quota
>> issues I've seen somewhere: use ~/tmp/ instead of /tmp. This
>> way, user's temporary files will be subject to
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
On Sat, May 26, 2012 at 08:20:46PM +0200, Carlos Alberto Lopez Perez wrote:
> On 26/05/12 19:43, Russ Allbery wrote:
> > Carlos Alberto Lopez Perez writes:
> >> On 26/05/12 19:13, Russ Allbery wrote:
> >
> >>> I find some of the assertions in this thread confusing. I've been
> >>> using tmpfs /t
On 05/26/2012 06:53 AM, Jonathan Callen wrote:
> On 05/25/2012 10:03 PM, Philip Ashmore wrote:
>> Hi there.
>>
>> First, here's what I'm talking about -
>> http://en.wikipedia.org/wiki/Permalink
>> Unfortunately Wikipedia doesn't offer permalinks itself, so
>> hopefully the above link won't "rot".
> 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
2012/5/26 Andrei POPESCU wrote:
> Maybe trying to kill two birds with one stone, but what if the display
> managers would set TMPDIR to ~/tmp/ (or ~/.cache/tmp or whatever)?
What's the point of dropping /tmp and then reinventing it in another
place on disk? Everyone could just continue using /tmp
Ted Ts'o wrote:
> If you're worried about installations which don't have much memory
> (i.e., the 512mb netbook), then swap is absolutely mandatory, I would
> think!
Not really. I have no legitimate programs that use more than 50% of my 1 gb.
I have an SSD. So why enable swap? If chromium goes cr
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 for people to not screw it up and dump large
> file
On Sat, May 26, 2012 at 02:32:15PM -0400, Ted Ts'o wrote:
> These days I'd argue that multi-user is such a corner case that it's
> not worth optimizing for it as far as defaults are concerned. If
> you're trying to run a secure multi-user system, you need to be an
> expert system administrator, ke
Josselin Mouette wrote:
> Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> commit the data on disk, and therefore can write it to disk whenever it
> likes, especially when the disk is not too used. There is no need to
> keep a journal nor to access the disk several times to u
Ted Ts'o wrote:
> The main advantage of tmpfs is that it gets wiped on reboot, and so it
> prevents people and applications from thinking that they can keep
> stuff in /tmp forever. It's also faster because a file system has to
> do extra work to make sure the files are preserved after a reboot.
Joey Hess writes:
> 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 for people to not screw it
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 priority that the system d-i
installs be broadly useful. d-i has at times n
On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
> On Fri, 25 May 2012, Thomas Goirand wrote:
>> for small files, and in that case, it's faster. In reality, it's
>> not that much faster, thanks to Linux caching of the filesystem,
>
> Under heavy filesystem IO load, yes it is. By several orde
On Sat, 2012-05-26 at 16:29 -0400, Joey Hess wrote:
> Ted Ts'o wrote:
> > The main advantage of tmpfs is that it gets wiped on reboot, and so it
> > prevents people and applications from thinking that they can keep
> > stuff in /tmp forever. It's also faster because a file system has to
> > do ext
> Again, I thought that:
> There is a single base directory relative to which user-specific
> non-essential (cached) data should be written. This directory is defined
> by the environment variable $XDG_CACHE_HOME.
>
> There is a single base directory relative to which user-specific runtime
> file
On Sat, May 26, 2012 at 08:23:31PM +, brian m. carlson wrote:
> I work for a company that develops software for shared-hosting
> providers. I can guarantee you that multi-user is far from a corner
> case. We employ 135 people and are growing, as is the shared-hosting
> market.
>
> For my per
On Sat, May 26, 2012 at 04:27:01PM -0400, Joey Hess wrote:
> Josselin Mouette wrote:
> > Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> > commit the data on disk, and therefore can write it to disk whenever it
> > likes, especially when the disk is not too used. There is no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/26/2012 03:09 PM, Philip Ashmore wrote:
> I'm happy and sad with this. Happy that Wikipedia provides
> permalink support. Sad that it didn't document it in its article
> about permalinks.
>
> Is there documentation on this feature somewhere?
>
Package: wnpp
Severity: wishlist
Owner: "Rogério Brito"
* Package name: tunesviewer
Version : 1.4.99.0
Upstream Author : Luke Bryan ,
Rogério Theodoro de Brito
* URL : https://sf.net/projects/tunesviewer
* License : GPL-2+
Programming Lan
Hello everybody,
for one of the packages maintained by the pkg-eucalyptus team (euca2ools), the
upstream source moved to GitHub, and we would like to try to maintain the
Debian package there as well.
I see that there is already a Debian account on GitHub
(https://github.com/debian), currently emp
* Charles Plessy wrote:
> Hello everybody,
>
> for one of the packages maintained by the pkg-eucalyptus team (euca2ools), the
> upstream source moved to GitHub, and we would like to try to maintain the
> Debian package there as well.
>
> I see that there is already a Debian account on GitHub
> (
Hi folks,
Has anyone seen/heard from Patrick recently? He has a number of packages
which are somewhat out of date (lmms specifically interests me), which
would be good to get sorted prior to the freeze.
--
Regards,
Miah
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
Hi
On Sunday 27 May 2012, Luca Falavigna wrote:
> Hi,
>
> I generated a list of source packages which have been removed from
> unstable, but are still kept into experimental for some reason. I
> excluded those which seem maintained, and generated a dd-list of the
> remaining ones. I will file rem
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 disk
This is easy to check:
$ cd /path/to/tmpfs
$ touch 1
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
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 platters even
> though they'll immediately get changed again. For fil
On Sat, 26 May 2012, Jon Bernard wrote:
> > I see that there is already a Debian account on GitHub
> > (https://github.com/debian), currently empty. Does it belong to a
> > Developer ?
> > Would it be availble to maintain the euca2ools package in ?
if there is no reply here it might be worth c
On Sun, May 27, 2012 at 02:25:20AM +0100, Miah Gregory wrote:
> Hi folks,
>
> Has anyone seen/heard from Patrick recently? He has a number of packages
> which are somewhat out of date (lmms specifically interests me), which
> would be good to get sorted prior to the freeze.
Here's an upload on 16
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 we would like to try to maintain
the
> > Debian package there as well.
> >
56 matches
Mail list logo
