241–250 of 361 posts
Earlier quoted context omitted.
If you miss a sync, your profile isn't going to be 'broken', just out of date.
if it happens during the sync you could be arbitrirly broken.
Earlier quoted context omitted.
SQLite is used exactly because it is so robust even on bad hardware. And you still need to check the data that SQLite is giving you.
Until you have a NFS homedir...
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…
Earlier quoted context omitted.
Why is there so much data in the session restore anyway? If the goal is to have the URLs of the currently opened tabs, I'd expect that just the given URLs should be enough? I think I've seen some unexpected stuff there like the images base64 encoded? Maybe there's enough users that would be satisfied just with the URLs? At least for them the "rewrite" would be seldom needed. Or, maybe to reformulate, which wild scena…
Agreed. If my computer crashes (once in a blue moon) I would be happy for it to just open the urls again. I don't care whatsoever about it keeping the current state of every tab. If any users do care about that, it should be optional (perhaps a tickbox in the preferences window).
Maybe I am not understanding this right, but is this saying that Firefox will continually keep writing to the disk while idle? Does anyone know more about this? Why would this be needed to restore session/tabs? Seems like it should only write after a user action or if the open page writes to storage? Even if it was necessary to write continually while idle, how could it possibly consume so much data in such a short p…
Maybe I am not understanding this right, but is this saying that Firefox will continually keep writing to the disk while idle? Does anyone know more about this? Why would this be needed to restore session/tabs? This is very much the feature working as intended: Firefox captures webpage state every 15 seconds, so a crash, power outage, accidentally closing the browser etc will not result in data loss for the user. For…
There is some element of slippery-slope. People say, "So what if your web browser uses 8GB of RAM for six tabs, you've got 16GB!". But I'd argue if every piece of software squandered RAM with such abandon, your machine would quickly choke.
It's also got some good shock value, like the one-paragraph web article that overloads your phone & generates 75MB of traffic.
I do wonder if their mobile version have a similar problem. I have noticed it chugs badly when opened for the first time in a while on Android, meaning i have to leave it sitting or a while so it can get things done before i can actually browse anything.
Earlier quoted context omitted.
And when you just spent 10 minutes finding the link you need, and your browser crashes, you're going to spend a lot more time again. There are plenty of cases where I'm really glad my browser re-opens all the tabs, with cookies in play etc. If your job includes having to use a web application for significant portions of said job, it's even more invaluable. I've worked on several applications that account for more tha…
That link you need & just found is saved in your history, isn't it? Session Restore is different from history, I'm pretty sure.
Earlier quoted context omitted.
if it happens during the sync you could be arbitrirly broken.
Only if the sync is the equivalent of: rsync [...] /dev/shm/.browser ~/.browser Instead of: rsync [...] /dev/shm/.browser ~/.browser.new && ln -sf ~/.browser.new ~/browser Or some such equivalent, i.e. doing the full sync and then atomically juggling a symlink around.
Earlier quoted context omitted.
> How about this: 29 out of 30 times, save only a diff to the previous data. 1 out of 30 times, save the complete data in compressed form. > > (I'm guessing there must already be functionality to diff a bunch of JSON somewhere in the millions of lines of code). That is actually a good idea we haven't considered yet. A bit too brute force for my tastes, but relatively easy to implement. We would need to determine how…
You could at least just compress the data with LZF or any of the really fast text compressors. It'll compress to about 30% of the size, it's easy to do, and it shouldn't add more than a tiny CPU overhead over formatting the JSON itself. It solves half the problem with like 15 minutes of work.
Then an hour of writing good tests.
Then lots of manual and automated testing on four or five platforms, and fixing the weird issues you get on Windows XP SP2, or only on 64-bit Linux running in a VM, or whatever.
Then making sure you don't regress startup performance (which you probably will unless you have a really, really slow disk).
Then implementing rock solid migration so you can land this in Nightly through to Beta.
Then a rollback/backout plan, because you might find a bug, and you don't want users to lose their session between Beta 2 and Beta 3.
Large-scale software engineering is mostly not about writing code.