Comment 14 for bug 1430620
Revision history for this message
| Egmont Koblinger (egmont-gmail) wrote | #14 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
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 and so on - storing in memory wasn't really among these. Tons of code have been built up around these assumptions.
The main question is not how/why we got here, but how to move on from here without reimplementing everything from scratch in a totally different way (and also: why move on at all). I mean re-writing a huge amount of code is also a possibility, but given the current resources for vte development it's unlikely to happen in the foreseeable future. We should accept where we are and find the simplest way to extend that to keep the data in memory. As I stated in the upstream bug, I believe the brand new memfd support of Linux seems to be the easiest way. (Or, as a quick workaround, you can already make it store the scrollback under a tmpfs-mounted directory. That's pretty much what memfd would give you, without requiring a tmpfs mount point.)
> Why turn things so far upside down to support an edge case (infinite scrollback left open for long periods of time)?
I can't see why the time should matter here.
We either properly support infinite scrollback (not as an edge case; without risking heavy swapping and OOM), or we don't. If we do, its scrollback has to reside on disk. I hope this is clear so far. The decision was made: we do support it. Most of the scrollback code was written with this decision in mind.
Have you installed newest vte with the patch I attached, or any other means of measuring its write activity? I really do want to see numbers before we move on. The numbers so far still give me an impression that even for extremely heavy terminal users gnome-terminal would still be responsible for probably less than 1%/year of SSD wear-out. I'm waiting for counter-proofs. (Could you please also describe in words what's your average terminal activity like? E.g. do you have tasks running in the background that continuously produce data, do you run big compilations that print a lot, etc.?)