*** This bug is a duplicate of bug 778872 ***
https://bugs.launchpad.net/bugs/778872
** This bug has been marked a duplicate of bug 778872
vte use causes /tmp file writing during text scrolling
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
** Package changed: vte (Ubuntu) => vte3 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1430620
Title:
gnome-terminal writes excessively to /tmp (affecting SSD drives)
To manage notificatio
Another week of heavily using gnome-terminal for everyday work, another
15 MB of data written. (I won't measure this anymore.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1430620
Title:
gnome-ter
After 1 week of usage, my gnome-terminals have written a total of 48 MB.
Out of this, about 40 MB was cating my favorite test file 4 times for
speed measurement purposes, and the remaining about 8 MB was the normal
tasks I performed, including management of several remote servers via
ssh, compilati
If it was for me, I probably would have dropped infinite scrollback
support. But apparently some people find it really useful.
We already have a certain code. It was designed with multiple criteria
in mind, including infinite scrollback support, efficient storing on
disk, compression, encryption a
Swap is the equivalent of main memory: the security issues are no
different. Nobody can complain about swap written to disk, as that's a
risk for any piece of main memory at any time. Why turn things so far
upside down to support an edge case (infinite scrollback left open for long
periods of tim
> Speed
Encryption added about 10% to the required CPU usage. Now, with in-
memory scrollback, would you keep it encrypted or not? If so, you'd keep
wasting CPU. If not, someone will come along and complain that it's been
written to disk (swap) unencrypted and it leaks data. But other apps
also ca
The oom killer will only come along if some epic long files have been
cat'ed to the terminal,
and infinite scrollback is selected. Speed, battery life, SSD life, energy
use and privacy are all reasons to have the common case be no disk writes.
--
You received this bug notification because you ar
I have seen the OOM killer killing an innocent process, and other
developers have expressed similar concerns too. That being said, I'm not
against storing the scrollback contents in memory as a possibility, see
the upstream bugreport for details. But I still can't see the SSD wear-
out issue justif
>How do you think gnome-terminal should handle that? Suppose you have 4
GB of ram, shall it consume up to 3 GB and then >starting using the
disk? Sounds not only hard to implement, but also why should it take
away RAM from other apps?
The Linux virtual memory system is highly adept at swapping out
The attachment "Count the amount of data written to /tmp" seems to be a
patch. If it isn't, please remove the "patch" flag from the attachment,
remove the "patch" tag, and if you are a member of the ~ubuntu-
reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad u
** Patch added: "Count the amount of data written to /tmp"
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/1430620/+attachment/4343310/+files/vte-ubuntu1430620-count-tmp-written.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
> But I run out of ram space very rarely.
Maybe because you don't allow large (let alone infinite) scrollback.
> It's highly elegant to keep volatile data in RAM unless RAM is full.
How do you think gnome-terminal should handle that? Suppose you have 4
GB of ram, shall it consume up to 3 GB and
@Egmont wrote:
"Running out of disk space is much less likely and effects the system less
badly than running out of RAM, and your RAM would eventually make it into the
disk (swap) anyways."
But I run out of ram space very rarely. It's highly elegant to keep
volatile data in RAM unless RAM is fu
With the max speed of vte measured on my computer (as I mentioned
above), producing 75 TB of scrollback data takes about half a year.
(With the compression, it'll be 1.5-2 years or so). Combine that with
the typical load average of your terminals in the long run (including
those times when the app
> As for SSD lifespan: I'm not really up to date, but a quick search
> suggests that it's not really an issue.
It's not as simple as that; for example manufacturers like Samsung will
disclaim warranties after writing more than 75 TB for smaller disks. See
https://www.samsung.com/global/business/se
Vte stores the scrollback buffer's contents on disk, that's what you see
there. See https://bugzilla.gnome.org/show_bug.cgi?id=631685,
https://bugzilla.gnome.org/show_bug.cgi?id=664611 (and maybe a few other
mainstream Gnome bugreports) about discussions and rationale why this
was chosen. Quick sum
See also http://ubuntuforums.org/showthread.php?t=1830432
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1430620
Title:
gnome-terminal writes excessively to /tmp (affecting SSD drives)
To manage not
18 matches
Mail list logo
