Re: Firefox profiles on a tmpfs (ramdisk)?
On 10/24/2010 10:12 AM, Jouko Orava wrote: > The question is, are Ubuntu developers interested in this? No. Have you tried using libeatmydata? The only key difference there should be with using tmpfs is that it effectively makes fsync() a noop. Aside from fsync and friends, the filesystem cache should make using the files normally just as fast, but firefox makes excessive use of fsync, which tends to slow things down. You should get similar performance from disabling the fsync calls to the normal on disk files, which you can do with libeatmydata. Unfortunately Mozilla views the syncing as vital to prevent the profile from being corrupted, and will not work to remove them. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Welcome to the "Ubuntu-devel-discuss" mailing list
On 10/24/2010 05:31 AM, León Asad Castillejos wrote: > Hi all, I'm León. > > I'm helping a friend to update to Karmic over IM. I've noticed a few... not > bugs, but little problems. You should compose a new message and set the subject to something appropriate instead of relying to the automated welcome message. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Firefox profiles on a tmpfs (ramdisk)?
Hello, For a couple of years now I've kept my active Firefox profiles on a tmpfs (mounted size=128M,mode=01777,atime,auto,rw,nodev,noexec,nosuid) on both my desktop workstation and on my minilaptop. It feels subjectively much snappier, but I haven't actually measured the difference. On the laptop, it also reduces disk usage, which is very nice. The profiles are unpacked from a tarball when firefox starts, and tarred back when firefox closes, using two script hooks in run-mozilla.sh: [ -x /usr/lib/firefox-profiles.sh ] && /usr/lib/firefox-profiles.sh load just before the final if clause, and [ -x /usr/lib/firefox-profiles.sh ] && /usr/lib/firefox-profiles.sh save just after the final if clause. The script itself is very careful to not fail (and not to overwrite the old tarball unless the new one is ok), and has never failed yet, even when Firefox crashes. I tried to get something similar upstream earlier: https://bugzilla.mozilla.org/show_bug.cgi?id=576707 but it was rejected for complexity reasons. If the Ubuntu Mozilla team were to add the script hook into Firefox -- noting that it does not change the behaviour by default, only if the hooked script actually exists --, I could create an Ubuntu package, which when installed creates the necessary tmpfs, profile tarballs, and modifications to the profile configs to limit the profile size (so that the tmpfs does not grow too large). All of the changes are also safely undoable if the package is removed. Each user can also choose which profiles, if any, are kept on the tmpfs. The question is, are Ubuntu developers interested in this? It does add changes to Firefox run-mozilla.sh script, which has to be maintained. (However, run-mozilla.sh does not seem to change often.) If there is interest for this, I could upload or e-mail the scripts (/usr/lib/firefox-profiles.sh for Firefox, and proposed maintainer scripts for a package setting up the tmpfs and moving Firefox profiles to a tmpfs.) (There are also some user interface related issues to think about, too. For example, should the package move all profiles to tmpfs by default, or should it have a GUI prompting the user on the next Firefox startup? Is there need for a migration tool, GUI or commandline, so that users could choose afterwards?) At the minimum, adding the script hook into run-mozilla.sh makes the testing much easier. Now, I need to modify run-mozilla.sh whenever Firefox is updated, which is a bit of a chore.. I'd be very happy to provide further information for those interested. Cheers, Jouko Orava -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Welcome to the "Ubuntu-devel-discuss" mailing list
Hi all, I'm León. I'm helping a friend to update to Karmic over IM. I've noticed a few... not bugs, but little problems. For example, the update manager for him showed at first 8 minutes left. Then it changed to 34, then to 9 again. In my opinion, the timing should be calculated having in mind the lowest KB/s ever received in the upgrade process, and then, slowly, cut off time if the network keeps stable and reaches high speeds. I think that the user shouldn't have "remaining time" displayed, but "maximum remaining time" instead. For example, if I'm in a hurry and only have 1 hour left with the computer, and I want to know if the process will complete, I prefer it to tell me it will take 1 hour and 5 minutes if it's gonna take 55 minutes, because there can be a lot of problems in the downloading process. Problems like unstable WiFi, stolen WiFi, messy cables, etc. Second. When the update manager detects a new version, don't just display a passive banner. It would be better if a OSD notification was displayed, showing the update manager icon. This notification would be displayed once or twice a week for 4 weeks, after that time, everything notifying of a new version would be disabled, while the end user could still update manually. I'm afraid i haven't been as clear as I wanted to be. If you need me to clear something out, please reply and I will try to explain. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
