Portable Seamonkey?
-
vladmir
- Posts: 319
- Joined: October 18th, 2004, 9:47 am
-
costinel
- Guest
what could be the difference between a 'portable seamonkey' and http://ftp.mozilla.org/pub/mozilla.org/ ... .win32.zip ?
-
herman
- Posts: 1034
- Joined: November 7th, 2002, 3:45 pm
costinel wrote:what could be the difference between a 'portable seamonkey' and http://ftp.mozilla.org/pub/mozilla.org/ ... .win32.zip ?
The zip is 'relatively portable', you just unzip it, and delete it, when it isn't needed anymore. The zip build uses Profile directories and other directories on the harddisk.
The 'Portable Application' is specially made for running from an USB-Stick.
http://portableapps.com/about/what_is_a_portable_app
It should care about two things:
Privacy - don't let temp data resting on the harddisk, id you are removing the USB stick.
Wear - don't use USB storage for frequently changing data.
A Flash byte can be written only about 100,000 times, or maybe a million times, buho modern flash is less reliable.
A flash byte can be written only if it was erased, and a flash byte can't be erased alone, a whole sector of flash bytes must be erased.
So if you want to change 1 byte in a sector, you've got to read the sector into a buffer, erase the sector, change the byte in the buffer, and write back all bytes from the buffer to the flash.
So imho on inserting the USB stick the 'portable App' will move it's frequently changing data from flash to RAM, maybe the program too,a nd before removing the USB stick will copy the data back from RAM to flash, and clear the RAM data to protect your privacy.
It could be this way, more or less, I don't know.
-
Mike Novack
- Guest
Well, I agree with most of that, Herman, but portable in the sense you just decribed imposes another "care" into your list.
Let's assume such a protable version of the app in practice. Upon loading, instead of USING the application data "in situ" it makes a copy into "core" (showing my age and mainframe origins), runs with that, then when closing down copies it back out onto non fugative storage.
PROBLEM --- to take our situation as an example, profile size ~1/2 gig. What you describe would work ONLY if people were willing to greatly limit that portable profile in terms of what might be kept in it (how many mail messages, how large) and what might be received into it (no incoming messages woth multi-meg attachments). Even then would be limited to systems with rather large amounts of core (possibly generous swap space might make viable in a 'nix). The point is that you would need MORE "core" than the capacity of the portable medium.
Alteratives? Yeah. Maybe instead, when starting allocate a large directory, name constructed say to incorporate time/date (unique), copy the data there from the portable storage, use this to run with, then in shutdown, copy back to the portable storage device and shred the disk pace used.
Let's assume such a protable version of the app in practice. Upon loading, instead of USING the application data "in situ" it makes a copy into "core" (showing my age and mainframe origins), runs with that, then when closing down copies it back out onto non fugative storage.
PROBLEM --- to take our situation as an example, profile size ~1/2 gig. What you describe would work ONLY if people were willing to greatly limit that portable profile in terms of what might be kept in it (how many mail messages, how large) and what might be received into it (no incoming messages woth multi-meg attachments). Even then would be limited to systems with rather large amounts of core (possibly generous swap space might make viable in a 'nix). The point is that you would need MORE "core" than the capacity of the portable medium.
Alteratives? Yeah. Maybe instead, when starting allocate a large directory, name constructed say to incorporate time/date (unique), copy the data there from the portable storage, use this to run with, then in shutdown, copy back to the portable storage device and shred the disk pace used.
-
Guest
- Guest