Tiny Core Linux

Tiny Core Extensions => TCE Tips & Tricks => Topic started by: roberts on January 21, 2009, 05:58:34 PM

Title: Beware Minefield
Post by: roberts on January 21, 2009, 05:58:34 PM
Just a heads up, a FYI.

I have heard that for some their backup time is very long.
If you have selected the minefield extension, it could be the reason.

Even though minefield was compiled optimally for binary size and dependencies, minefield, aka, firefox is huge.
Firefox now uses sqlite databases to store many options and history of your browsing, sites visited, downloaded files, etc. In addition there is a huge file XUL.mfasl. All of these reside in your home/tc directory. That's right they will be in the default backup. There goes the backup time and space required.

Even though TC is tiny, your choices can result in bloat and slower running systems.

Personally, I prefer the Opera extension from Curaga. It works well with flash and sound,  i.e., the youtube test.

If you prefer to stay with minefield, you can choose to add these very large files to your .xfiletool.lst and thereby exclude them from your backup. Note, that minefield will still run fine, but some options or settings may not persist as such setting may likely reside in a now excluded file. On the otherhand, you may like it that minefield will not be recording sites visited and files downloaded. Do we even know how large such databases will grow?

Anyways, just wanted to bring this to your attention. Choices for either Opera vs Minefield, or tuning Minefield, or accept these large files.

Here is my .xfiletool.lst with minefield mods
Code: [Select]
Cache
XUL.mfasl
opt/.tce_dir
home/tc/mnt
home/tc/.adobe/Flash_Player/AssetCache
home/tc/.macromedia/Flash_Player
home/tc/.opera/opcache
home/tc/.opera/cache4
home/tc/.Xauthority
permissions.sqlite
cookies.sqlite
places.sqlite
search.sqlite
formhistory.sqlite
content-prefs.sqlite
downloads.sqlite
XPC.mfasl

HTH YMMY
Title: Re: Beware Minefield
Post by: bigpcman on January 21, 2009, 06:16:04 PM
Thanks for the tip on that one Robert. Guess I'll start using opera.
Title: Re: Beware Minefield
Post by: tobiaus on January 21, 2009, 07:42:32 PM
i would be wrong not to point out the difference it makes (for me) to delete the one sqlite list (no, urlclassifier is not even listed in roberts post, perhaps it's not in tc) of malware sites, and to delete your cookies (cache, and other things ff can be set to delete on exit) as an alternative to running opera.

opera is a very good, very fast, quality browser if minefield does not work to your satisfaction, and if you're happy browsing with something closed source. perhaps a kazehakase extension would be very good. i believe it is based on gtk(2?) and gecko, and is just the sort of thing to run in tc, yet is just as modern as ff and opera.
Title: Re: Beware Minefield
Post by: roberts on January 21, 2009, 09:05:45 PM
The files mentioned were gleamed from an ls -lSr of the .mozilla/firefox/xxxx.default directory. YMMV
Title: Re: Beware Minefield
Post by: wiak on April 25, 2009, 05:14:41 PM
All of these reside in your home/tc directory. That's right they will be in the default backup. There goes the backup time and space required.

More generally (not particularly or at least specifically to do with Minefield): if a symlink to a file is stored in home/tc is it only the symlink that gets backed up or the file it links to?
Title: Re: Beware Minefield
Post by: ^thehatsrule^ on April 25, 2009, 05:28:19 PM
The symlink itself should be.
Title: Re: Beware Minefield
Post by: Jason W on April 25, 2009, 05:59:26 PM
Waik, you have a good idea if you are thinking about placing a .mozilla directory on permanant storage and creating a symlink to called /home/tc/.mozilla.  I normally run with my /home directory in RAM and this is a valuable tip.  I have placed the symlink in my backup and my backup size as well as my RAM usage stays smaller.
Title: Re: Beware Minefield
Post by: wiak on April 25, 2009, 06:09:39 PM
thinking about placing a .mozilla directory on permanant storage and creating a symlink to called /home/tc/.mozilla. 

Exactly what I planned.
Title: Re: Beware Minefield
Post by: wiak on April 25, 2009, 06:34:24 PM
I'm also wondering if this provides an alternative to using tcz's, when you don't want a tce to end up extracting itself into RAM.

minefield.tce, for example, ends up extracting into /usr/local/firefox/

(similarly, firefox.tce extracts into /usr/local/firefox-official/)

Would it not be possible (as an option if you don't want the tce to extract to RAM) to make /usr/local/firefox/ (or even the whole of /usr/local for that matter) a symlink to a permanent partition /usr/local/firefox/ ?
Title: Re: Beware Minefield
Post by: ^thehatsrule^ on April 25, 2009, 06:39:51 PM
A better solution already exists: see the local= boot option (check out "core concepts" for more info)
Title: Re: Beware Minefield
Post by: wiak on April 25, 2009, 06:56:42 PM
Yes, I knew about the local=boot option, and it's an attractive one. However, as Core Concepts says, it suffers from the disadvantage of "system rot" over time. Using tcz doesn't (as far as I understand the concept used) and I wonder if what I suggested above is an alternative to  using tcz?

If so, what I'm suggesting is potentially surely a "Fifth Mode of Operation" using PPR/TCE but where the uncompressed TCE  can be kept (as an alternative) on  permanent/persistent storage giving the RAM-saving-efficiency of a full-install (scatter) but without the system rot over time.
Title: Re: Beware Minefield
Post by: Jason W on April 25, 2009, 07:03:40 PM
Unless the directory where your real files are is not writable, system rot will occur all the same even if there is a symlink being used in the system to point to the directory containing the files.
Title: Re: Beware Minefield
Post by: wiak on April 25, 2009, 07:13:40 PM
Yes, but TCE's are reloaded fresh everytime. That's one of the advantages is it not? What I'm suggesting is the same: I'm suggesting that TCE's could also be uncompressed onto persistent storage, with that being done on each reboot (as an "alternative" to that happening into RAM as at present). The persistent storage location has to be writable, but it doesn't need to be backed up between boots - same as if the TCE was uncompressed in RAM. The advantage is the RAM saving (giving up loading speed for more free RAM). So in that scheme there is no system rot.
Title: Re: Beware Minefield
Post by: Jason W on April 25, 2009, 07:37:58 PM
That is basically what happens if you use a tclocal mount and also keep your tce extensions in your tce folder to be loaded upon boot.
Title: Using symlink to temporarily free some tce/ppr system RAM
Post by: wiak on April 25, 2009, 09:19:42 PM
I see what you mean; it is the same as tclocal really.

It's still a good "trick" though, if you have a PPR/TCE system and suddenly need more RAM without rebooting.

For example, I just did the following and freed up around 70 MB of RAM:

1. I'm still using TC version 1.2 and have firefox.tce installed in /tce and boot frugally via grub with kernel option tce=hda4/tc1.2/tce in a PPR/TCE based system (my tce store being on /dev/hda4 in folder tc1.2 with my downloaded optional tce's being in tc1.2/tce/optional).

 [For variety of boot choices, I actually have various tce directories, all populated with symlinks pointing to my main optional tce store - as per a post made by softwaregurl at http://forum.tinycorelinux.net/index.php?topic=155.0 (http://forum.tinycorelinux.net/index.php?topic=155.0)]

2. Once booted into TC, I copied the whole of /usr/local/firefox-official to /mnt/hda4/tc1.2/persistentfirefox-official

3. Then I deleted /usr/local/firefox-official (which frees up the RAM) but doesn't remove the Firefox icon from wbar.

4. In a terminal (as root user) I then created a symlink to the persisent copy of the firefox folder:

Code: [Select]
ln -s /mnt/hda4/tc1.2/persistentfirefox-official /usr/local/firefox-official
Clicking on the Firefox link brings it all up as usual, same configuration (since still have /home/tc/.mozilla folder), but several tens of extra free RAM now available.

I wouldn't normally bother doing the above but might come in handy on occasion...
Title: Re: Beware Minefield
Post by: tobiaus on April 26, 2009, 07:26:47 PM
Yes, but TCE's are reloaded fresh everytime. That's one of the advantages is it not? What I'm suggesting is the same: I'm suggesting that TCE's could also be uncompressed onto persistent storage, ...in that scheme there is no system rot.

as far as i know, tce's will not overwrite existing files, system rot would occur for any files that exist before tce's are loaded. that's a very large margin for the same disadvantages. i think tcz's are different.
Title: Re: Beware Minefield
Post by: wiak on April 27, 2009, 12:17:42 AM
In PPR/TCE mode the tce's are loaded fresh, so the underlying system is "pristine". Of course the user's mydata.tgz then overwrites that pure system, which is hardly avoidable; except that it's pretty easy to keep backup's of previous mydata.tgz files so that you can quickly return to a known stable situation. The main thing is to keep the underlying system stable and clean; which is why such installation methods are superior to full hd installs - where actual main system rot is a constant danger.
Title: Re: Beware Minefield / Firefox generally
Post by: mcewanw on May 03, 2009, 06:26:16 PM
I'm wondering if the information provided in the following two links would help with backup (and speed) issues. One concerns using tempfs to store profile info and stopping sqlite's ‘urlclassifier*.sqlite’ files growing hugely out of control, and the other concerns compressing sqlite databases to effect some (large?) speed increases in Firefox usage. I can't try either technique myself at this moment (but certainly intend doing so when I next have some time available for such, whenever that will be!):

http://icehot.wordpress.com/2009/01/04/speed-up-firefox-by-mounting-the-profile-in-tmpfs/

http://icehot.wordpress.com/2009/01/10/linux-firefox-performance-tip/
Title: Re: Beware Minefield
Post by: tobiaus on May 03, 2009, 07:23:07 PM
i didn't look at the second one. the first one probably won't help, as ff pretty much already runs in "tmpfs" or similar.
Title: Re: Beware Minefield
Post by: mcewanw on May 03, 2009, 07:51:35 PM
Yes, I agree regarding tmpfs. The first link however also gives advice about using about:config to deal with urlclassifier sqlite growth excesses.
Title: Re: Beware Minefield
Post by: thane on May 07, 2009, 04:33:23 PM
Would robert's concerns about Minefield/Firefox also apply to Seamonkey?
Title: Re: Beware Minefield
Post by: tobiaus on May 07, 2009, 05:17:42 PM
Would robert's concerns about Minefield/Firefox also apply to Seamonkey?

quite possibly. i use minefield regularly, i'm even using it in 2.x and it's fine. note that i'm not making a backup i'm using cloud (but when i use usb and run backup, i'm also using minefield.)

the big difference is i clear my cache when i'm done, and i don't use the massive bookmarking features or keep history set for 90 days (that is a stupid setting, blame mozilla.). you can also set your cache to something more reasonable, but clearing private data when you're done makes all the difference in the world. if i ran backup right now, minefield would not be an issue.

you can also just add the cache (and anything else you don't want to save from boot to boot) to .xfiletool.lst ... i really don't understand why the bad review of minefield. configured properly it shouldn't be any different than any other browser. but if you use it "out of the box," robert's right, don't back all that up you won't like it.

one other thing is flash. without flash many sites are faster. on an old machine using flash9 instead of 10 helps. using 1.x instead of 2 might also help, but 2.0 isn't even release yet, we'll see.
Title: Re: Beware Minefield
Post by: jpeters on May 09, 2009, 10:41:27 AM
I like the idea about making links to /tc  whenever possible.  How about .wine, for example? Using a link shaved about 30 seconds off my boot time.  Even without /Program Files, it still runs about 47M.