151–160 of 361 posts
uBlock also keeps writing "hit counts" to disk all the time, as well as for some strange reason they've chose database page size to be 32k so each update writes at least 32kB.
Chrome, on my system, is even more abusive. Watch the size of the .config/google-chrome directory and you'll see that it grows to multi-GB in the profile file. There is a Linux utility that takes care of all browsers' abuse of your ssd called profile sync daemon, PSD. It's available in the debian repo or [1] for Ubuntu or [2] for source. It uses `overlay` filesystem to direct all writes to ram and only syncs back to…
What is the typical memory usage of this for normal web browsing?
overlaid 2.0G 128M 1.9G 7% /run/user/1000/codemac-firefox-3ckuo4v7.default
Earlier quoted context omitted.
I made a simple firefox/chrome extension for people like you and me that horde tabs. You might find it useful to find tabs and quickly navigate to them by clicking on the link in the list. It's free and open source. The github page has a gif showing usage. Chrome Extension: https://chrome.google.com/webstore/detail/tabist/hdjegjggiog... Firefox Extension: https://addons.mozilla.org/en-US/firefox/addon/tabist/ source…
Your chrome link is broken. Anyway I used an extension like this for awhile, called session buddy. But now I just use control+D and bookmark all my tabs. Then you get bookmark syncing, and you can save your tabs when you export bookmarks, or wget them to have a local archive, etc. It's just more convenient, and one less extension I have to worry about stealing my personal information or bugging and corrupting my data…
FWIW, Mozilla looks at all extensions before fully approving them and the app is fully open source and fairly easily vetted if people are worried about that sort of thing.
Thanks for the feedback!
Hi, I’m one of the Firefox developers who was in charge of Session Restore, so I’m one of the culprits of this heavy SSD I/O. To make a long story short: we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plent…
Earlier quoted context omitted.
Much of the recent breakage was to introduce essential features that users have been loudly asking for for years, such as multi-process support and content processes in a security sandbox. If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.
Progress at what cost? Does maintaining security have to also mean breaking the systems that pay my bills?
Hi, I’m one of the Firefox developers who was in charge of Session Restore, so I’m one of the culprits of this heavy SSD I/O. To make a long story short: we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plent…
What would an updated version of Session Restore look like? I mean, what would be your vision for a new version?
On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that:
- it's performance-critical;
- it's safety-critical;
- we have users with 300+ Mb of data in their Session Restore and JSON isn't meant for this scale of data;
- we wouldn't need to rewrite x Mb of data every 15 seconds, just a per-tab update;
- if we're using a relational database, it would be easier to trust the code to not screw up with the data;
- we wouldn't need to load the entire Session Restore upon startup.
(On the minus side, this might make backups a bit more complicated.)
On the front-end, we would need a high-level API for Session Restore, which would let us do things such as accessing per-tab data, (de)hibernating tabs, etc. Oh, and it would need to be accessible by WebExtensions.
In the middle, we would need to re-engineer Session Restore to make sure that we don't need to maintain this huge object representing the entire state of the session. We would also need improvements e.g. to cookie management, to avoid having to re-collect cookies so often.
Earlier quoted context omitted.
You also need to handle all corner cases where one of the intermediary diffs gets corrupted (you can't generally assume in a program like Firefox that data you write out is going to be readable in the future because lol common hardware). Or where the diffs are larger than a fresh snapshot. And you absolutely can't get it wrong. It's something that sounds easy until you actually try to get it coded up and shipping. I…
Firefox does generally assume that the filesystem is reliable (as long as you use fsync properly etc). Witness eg its reliance on SQLite for data storage.
Hi, I’m one of the Firefox developers who was in charge of Session Restore, so I’m one of the culprits of this heavy SSD I/O. To make a long story short: we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plent…
Firefox has been terrible for disk access for many years. I remember I had a post install script (to follow, I never actually automated) that I would run through in my linux boxes back in about 2003 that would cut down on this and speed up the whole system. Basically chattr +i on a whole bunch of its files and databases, and everything's fine again...
There's been some development the last 13 years. Chrome was also pretty crappy in 2003. /s
Earlier quoted context omitted.
The web browser is basically everything I do, though. My email is in it, my code review is in it, my IM is in it, on some of my machines my terminals are in it (via the Chrome mosh app).
Email/code review/IM/terminal doesn't justify 12GB of writes per day (and attendant hit to drive endurance/battery life). Those are lightweight activities. Emacs can do all those things and it doesn't write to disk unless you tell it to. Heck, even bloated beyond belief Outlook + Visual Studio + Skype + PowerShell wouldn't create anywhere near that kind of background activity.