upgrading Seamonkey 1.0.8 to 1.1.4

[miriam]

Seamonkey 1.0.8 has a major drawback. It is unable to automatically re-use the program already loaded into memory, so if the user tries to start another instance of Seamonkey Puppy uses an ingenious script to put up a message to ask the user to open it from the existing instance. This forces Seamonkey to use the currently loaded code rather than loading it all into memory again. This is fine, but my parents found it confusing, and I found it annoying. When I checked out the Seamonkey site I found that more recent versions of Seamonkey automatically re-use loaded code, avoiding the whole problem.

Here is how I installed Seamonkey 1.1.4.

I downloaded the latest version of Seamonkey (1.1.4) from
http://seamonkey.ilias.ca/downloads/
then (after backing up the old Seamonkey files and my email and bookmarks, for safety's sake) I installed it. It was totally painless! I couldn't believe it was so easy!

I chose to download the seamonkey-1.1.4.en-US.linux-i686.installer.tar.gz file. Clicking on the downloaded file lets you unpack the installer. It doesn't matter where you unpack it to. Now open the "seamonkey-installer" folder that was created by the unpacking process and either click on the "seamonkey-installer" file inside the folder, or open a terminal (also called a console) in that folder and type in "./seamonkey-installer" without the quotes. (Using the terminal can sometimes be useful to let you see helpful error messages when all doesn't go properly.) Just answer the questions and click the appropriate buttons and you are done. Easy.

Now, in order to use Seamonkey from Puppy's desktop I needed to edit the
/usr/local/bin/defaultbrowser
script to be:

Code: Select all

#!/bin/sh
#exec mozstart "$@"
exec /usr/local/seamonkey/seamonkey "$@"

and
/usr/local/bin/defaultemail
script to be:

Code: Select all

#!/bin/sh
#exec mozmail "$@"
exec /usr/local/seamonkey/seamonkey -mail "$@"

There is a slight problem that I haven't yet solved in getting /usr/local/bin/defaulthtmleditor to run while another Seamonkey window is open. For some reason it insists on starting up the profile manager window. Until I've solved it I've edited the
/usr/local/bin/defaulthtmleditor
script to be:

Code: Select all

#!/bin/sh
#exec mozedit "$@"
exec /usr/local/seamonkey/seamonkey -edit "$@"

and I either start Seamonkey's HTML composer before any other Seamonkey windows are open, or use the old method of starting it from an existing instance.

The new version of Seamonkey definitely re-uses any already loaded code. I ran some tests that confirmed RAM use is the same whether multiple instances are started from the desktop icons or from the same window.

Best of all, the new version seems to be faster than the old, slow one. Added to that, the new version has a bunch of security fixes and a lot of nice added features, like spell-check as you type, thumbnails of pages behind browser tabs that pop up when you hover your mouse over the tab, and much more.

The new version's installer is not much bigger than the old one (14 MB compared to 13 MB), but I haven't checked out how much bigger that expands to.

A small problem

After installing Seamonkey I found gxine wouldn't play. A little bit of investigating showed that it relies upon some of the Mozilla libraries, and the $LD_LIBRARY_PATH to them is set in the /etc/profile file when Puppy is starting up making the mozilla libraries accessible to all. Unfortunately, the new Seamonkey loads to a new place that the profile script doesn't know about.

There are 2 easy solutions.

Less than optimal solution:
The fix is easy. Just change the appropriate couple of lines in the /etc/profile script somewhere between line 30 to 46, depending on your Puppy version.

Change from

Code: Select all

if [ -e /usr/lib/mozilla ];then
 LD_LIBRARY_PATH="/usr/lib/mozilla:$LD_LIBRARY_PATH"
fi

to

Code: Select all

#if [ -e /usr/lib/mozilla ];then
# LD_LIBRARY_PATH="/usr/lib/mozilla:$LD_LIBRARY_PATH"
#fi
if [ -e /usr/local/seamonkey ];then
 LD_LIBRARY_PATH="/usr/local/seamonkey:$LD_LIBRARY_PATH"
fi

Of course if you choose a different location for Seamonkey then you'll need to alter the code accordingly.

As you see, I commented the old path out. It doesn't hurt to leave it uncommented if you have removed the old Seamonkey, but every line commented out is a line not run and a faster startup. I'd advise definitely commenting it out if you don't remove the old Seamonkey installation.

A simpler, better solution:
There is a better way to make Seamonkey's libraries available to other programs like gxine than editing the /etc/profile script. All that is needed is to simply delete the old /usr/lib/mozilla shortcut and make another new one that points to the new Seamonkey folder.

There are several ways to make such a link.

Probably the easiest is, in RoxFiler, to drag the new Seamonkey folder using the middle mouse button if you have one (note that the scroll wheel doubles as the middle mouse button when you press it instead of rolling it). When you release the file a pop-up menu asks if you want to copy, move, make a relative link, or an absolute link. I generally prefer absolute links when the files have independant positions, though it doesn't really matter here.

Another way is to open a terminal (console) and enter

Code: Select all

cd /usr/lib
ln -s /usr/local/seamonkey mozilla

This assumes that you have followed the default and installed the new Seamonkey in /usr/local/seamonkey but if you have given the folder a different name or put it in a different place you will need to change the path accordingly. For instance if you continue the current Puppy tradition of putting it in /usr/lib/seamonkey-1.1.4 then you'll probably want to make that

Code: Select all

cd /usr/lib
ln -s seamonkey-1.1.4 mozilla

No path is needed because you are referring to a folder in the current directory.

[miriam]

Updated with a better method to make the library path available to other programs like gxine. See above.

[ecomoney]

Thanks for this tip. It definetely makes thing more confusing. I wonder if it would be possible to add this to a pup_2xx.sfs file so it would be added to the applications running in RAM and so be faster. Im thinking of adding this upgrade to ecopup.

[Bruce B]

Thanks for this tip. It definetely makes thing more confusing. I wonder if it would be possible to add this to a pup_2xx.sfs file so it would be added to the applications running in RAM and so be faster. Im thinking of adding this upgrade to ecopup.

Probably the next Puppy will have the newest SeaMonkey.

Regardless of where you install the application, it always runs in RAM. The speed advantage is on loading time depending mainly on how fast the read time on storage device, CPU power, RAM speed and etc.

[mcewanw]

Regardless of where you install the application, it always runs in RAM.

I'm not sure about this because I haven't checked it out thoroughly as yet, but I wonder if the above is always correct Bruce B? Does the whole of pup_save.2fs load into RAM or does it depend on how much RAM is available in a frugal install? If it doesn't all load in, then Seamonkey may be swapping parts of itself in and out and hence running slower. Also, I was under the impression that pup_save.2fs is not a compressed (for example, squashed) filesystem. Does that mean that it takes up considerably more space in RAM than it would if loaded like an squashed sfs file? When I did away with Seamonkey-1.0.8 on my own system, and replaced it with Firefox, I remastered the pup_217.sfs (using Menu > Setup > Dougal enhanced ...) to truly save the space of the erased Seamonkey and also to make the sfs smaller so that it would, I presumed, occupy less RAM. But I'm still not sure if my thoughts are correct about all that.

[Bruce B]

Yes programs always run in RAM for our purposes. Exceptions would be Virtual RAM as in a swap device, but that is still considered a RAM extension.

Say you are running Geany the text editor. On a frugal. it is read from the .sfs and copied into RAM. On a normal it is copied out of the filesystem into RAM. Additionally the text files you are editing are copied from their storage space into RAM, the editing takes place in RAM and changes saved to their respective storage places.

In order to help your certainty of this, maybe if you ran top, then opened some applications you will be able to see the specs on the RAM occupied by the opened apps. Check the percentage of memory to the left of the app name.

[Bruce B]

About the changes you made. Removing SeaMonkey saves the space it occupied in the .sfs file. If you have enough RAM the entire .sfs file will load into RAM. You will have as much more RAM to work with as the space saved by removing SeaMonkey.

If you install Firefox then you had the space Firefox takes up in a compressed filesystem (.sfs) which is much less than the space it would take in an uncompressed filesystem, such as a normal install.

A comprehensive program like SeaMonkey would likely not load every single file. It would load what it needs according to how it's programmed. If more is needed it would go back and get what is needed. I don't say this because I'm intimately familiar with SeaMonkey, rather its a somewhat general rule of thumb for very large programs that do a lot of things.

(With my SeaMonkey I have a 200 MB cache on a filesystem in RAM. Each time I reboot, which is every few days, the cache disappears. Suffice it to say, my SeaMonkey really uses RAM)

I've noticed that most standard sized .mp3 files get copied to RAM, because I've been able to delete them while they are playing and they continue to play after deletion. This is when the program playing the file doesn't have a lock on it, otherwise it can't be deleted.

With things like 8GB DVD movies, they can't be loaded into RAM because of their size, so they are streamed and played in RAM.

[mcewanw]

1.

A comprehensive program like SeaMonkey would likely not load every single file. It would load what it needs according to how it's programmed.

But that is part of what I was saying, surely (that, along with Seamonkey loading parts of itself back and forwards into RAM from pup_save on hard disk):

On machines in which true physical RAM is beginning to run short

Seamonkey may be swapping parts of itself in and out and hence running slower

Yes programs always run in RAM for our purposes. Exceptions would be Virtual RAM as in a swap device, but that is still considered a RAM extension.

Though swap is used to effectively extend RAM, it is not real physical RAM; swap is on the external storage device, which is usually a hard disk; and thus much slower than physical RAM.

Also, if miriam's Seamonkey is installed on the pup_save file (rather than the pup_xxx.sfs file) the various bits of it may not have been loaded into physical RAM waiting to be used:

Quote from "how puppy works" http://www.puppylinux.com/development/h ... works.html:

"The second time that you boot your Puppy live-CD, assuming that you chose to save the previous session to a pup_save.3fs file in a Linux, FAT or NTFS partition, Puppy will be in PUPMODE 12. . . . What has happened here is that at bootup Puppy found the pup_save.3fs file is on a fast hard drive partition, so decided to mount it directly on the top layer. Thus, there is no tmpfs ramdisk intermediary. File pup_save.3fs is directly read and written to."

However, 'fast hard drive' (as mentioned in the above quote) is still, as I said before, "much slower" than physical RAM.

Regardless of where you install the application, it always runs in RAM

On the contrary, as ecomoney suggested, Seamonkey may run faster if it is installed in the pup_xxx.sfs rather than in the pup_save file.

2.

Also, I was under the impression that pup_save.2fs is not a compressed (for example, squashed) filesystem. Does that mean that it takes up considerably more space in RAM than it would if loaded like an squashed sfs file?

On this point, sorry, I didn't make myself clear. I assume that miriam has installed Seamonkey 1.1.4 without remastering. That, I was suggesting, means that her installation of Seamonkey is being installed in pup_save.2fs (assuming frugal install). I am of the impression that pup_save.2fs isn't a squashed filesystem and hence, if that filesystem is loaded wholly into RAM whilst containing Seamonkey, the true size of Seamonkey will be using up RAM. Or is pup_save.2fs in fact squashed? I think its just an unsquashed ext2 file.

Of course, my installation of Firefox is different. Yes, it is installed in the squashed filesystem pup_217.sfs, which saves RAM space when the filesystem is loaded.

[Bruce B]

1.

A comprehensive program like SeaMonkey would likely not load every single file. It would load what it needs according to how it's programmed.

But that is part of what I was saying, surely (that, along with SeaMonkey loading parts of itself back and forwards into RAM from pup_save on hard disk):

If it did as you suggest, I wouldn't consider it very well written.

Top will give you some details about what's happening with Sea-Monkey in RAM. One could load Sea-Monkey and see if memory used is static. Not that this is a high tech way of monitoring things, but it's a tool that's easy to use and included with Puppy.

There is a consideration I have about an interchange between the user profile and SeaMonkey - the interchange is a lot of writing and a fair amount of reading and updating cache and write backs to disk as needed. Web pages and other objects get cached in RAM, flushed, then written to disk, the disk caches get flushed. Lots of things happen. History is constantly changing. Bookmarks added, etc.

With SeaMonkey the reads and writes are fairly intensive and happen in both directions. But the actual running still happens in RAM.

------

I guess my major point is that a computer has storage devices and RAM - the actual operations such as running programs and client files happen in RAM, although the programs (depending on the program) interact with disk in terms of reading, writing and updating.

[mcewanw]

1.

A comprehensive program like SeaMonkey would likely not load every single file. It would load what it needs according to how it's programmed.

But that is part of what I was saying, surely (that, along with SeaMonkey loading parts of itself back and forwards into RAM from pup_save on hard disk):

If it did as you suggest, I wouldn't consider it very well written.

Oh well.

My original post no doubt wasn't my best, though I was trying my best in the limited time I had available to help. Hopefully what I have written since has helped overall at least with some readers' understanding of the technical issues involved; that is absolutely all I am concerned about. If I'm wrong about a technical issue, I'm perfectly happy for someone to point out my mistakes and clarify them, thanks.

As for "top", I taught Linux Kernel programming for years, and even in that work, top was among the most used tools. I'm no expert in UNIX/Linux generally though (no expert in anything IMHO); I've been using Linux and UNIX in some shape or form for decades, but every distribution has its foibles, and I've tended to avoid linux admin work when possible.

Yes, it's technically important to emphasise, as you have done, that for a piece of code to be running (i.e. in the actual run state) it has to be in physical RAM at that time.

[mcewanw]

By the way, I'm happy to "argue" about technical issues until the cows come home, since I believe that such debate, however it goes, helps to reveal the underlying complexities. However, as soon as I am faced with a personal comment, challenging, for example, by ability to write (correct or otherwise as it might be) I tend to go a bit deaf. Not that I'm offended (!); indeed it amuses me slightly.

[Bruce B]

Sorry, really.

I guess I misunderstood.

[mcewanw]

that's ok.

[ecomoney]

Popular saying in professional IT circles

"To Err is human, to really foul things up it needs a computer"

Glad that between us weve got to the bottom of how this thing works, good bit of communication. So, how would the .sfs be upgraded to this version. I know an .sfs can be "mounted" and edited. Theres even a .sfs editor to do it. Would this be the way to go on?

[mcewanw]

So, how would the .sfs be upgraded to this version.

I presume you are referring to pup_217.sfs? If so, I would say that it's just a matter of remastering using JWM > setup > Dougal's advanced remaster CD (but only after you have the new Seamonkey installed as described by miriam, and the old Seamonkey removed, and anything else removed that you don't want to go permanently from your pup_save.2fs file into the about-to-be-remade pup_217.sfs). That at least is how I installed Firefox instead of Seamonkey. Dougal's script gives the choice of remastering the whole iso, or just the pup_217.sfs.

You need to take care though because as miriam points out:

the new Seamonkey loads to a new place that the profile script doesn't know about.

As miriam says, you need to make sure that, for example, gxine can find the mozilla libraries it requires. The relevant libraries have been documented in several places in the forum. I gathered some of the links when writing about that myself in thread:

http://murga-linux.com/puppy/viewtopic.php?t=21545

I imagine that the versions of these libraries in the newer Seamonkey will work fine with gxine, though I don't know; unfortunately, that wasn't the case with the equivalent Firefox libraries. Assuming the new libs are okay with gxine etc., you should be able to delete (using rm -f or Rox) all the old Seamonkey stuff (check miriam's notes for its locations). You just have to make sure that the system can can find the new installation libraries etc as per miriam's description. However, you might want to hang on to the old plugins' directory contents, just in case it turns out that you still need, for example, the flash plugin and whatever from there. And make backups of the old pup_save.2fs and pup_217.sfs before you do anything of course!

Basically, you shouldn't remove anything until you have the new Seamonkey working to your satisfaction, after installing it, but prior to remastering your pup_217.sfs (I'm assuming here that you are running from CD or a frugal HD install). In practice, until you do the remaster, the old Seamonkey isn't "really" physically deleted from the pup_217.sfs even though you remove all its files and directories with the relevant commands (such as rm -f); it's actually just hidden or "masked-out" by the system and thus invisible in the running system, but it still continues to take up its previous physical space in the pup_217.sfs file.

The real deletion (and the space-saving) occurs, however, when you do the remastering. That process takes note of the hidden stuff and truly deletes it whilst merging everything in your existing pup_save.2fs file permanently into the pup_217.sfs. Personally, I like to start with a new pup_save.2fs when I want to remaster the original pup_217.sfs. I remove the stuff I don't want on the pup_217.sfs, and add the new stuff I want, then I remaster.

Alternatively, of course, the old Seamonkey could be removed manually from pup_217.sfs using an editor specially designed for that purpose, as you suggest. However, I've never tried that method myself; it does have its appeal though.

To be honest, ecomoney, I'm surprised your asking about this. I have noticed that you have been contributing to puppy linux in a big way for a long time, so I would have imagined you were very familiar with the remastering process. It is possible though that you have never needed to do it; puppy, as you know, is pretty good out-of-the-box. The other possibility is that I am misunderstanding what you are asking, in which case please disregard everything I have been writing about here!

Finally, there is also the possibility that I have failed to understand the remastering process and its effects myself; I've only quite recently started using puppy linux in a big way, though I have been burning the candle at both ends in that endeavour for several weeks now. Of course, just as I approach satisfaction at how I now have my own machine, Puppy 3.0 is coming out (!), and I won't be able to resist the new offerings or the extra work that is bound to give me...

[ecomoney]

Hi mcewanw.

Your right about me being a novice when it comes to hacking in the linux basics. I come from an quite academic computer background.I think its a testiment to the people that are good with code, and their helpfulness, that the cybercafe was set up and there are so many people around here with puppy on their computers at home (about a hundred and growing at best guess). I still cant compile, make .pups and .pets, remaster etc. I have a vague idea what a library is, and it was only last night I opened up the initrd.gz and pup_2.15.sfs files for the first time and took a look at how they work.

Most of what I do is gather feedback and bug reports from end-users at the cybercafe and during my teaching and feed that back to the real developers who understand the inner workings. I also write a few newbie tutorials and pass news onto the team.

I think I could just about open the pup_215.sfs with the decompressor file and replace the seamonkey directory with one from the new version. Would that work? if not what other steps may work. Currently Im working on ecopup (2.15ce based) and have done a lot of work on useability and appearence that I wouldnt want to lose to add this functionality.

Thanks for getting back and for the tutorial, the more I read the more it makes sense.

[mcewanw]

It seems to me that either method would work. Whatever happens you should remove the old Seamonkey stuff (in pup_215.sfs) and add the new Seamonkey stuff (pre-configured and ready to fly...). I suppose you "could" do that by opening up the pup_215.sfs file (by decompressing it as you say), or a copy of it, perhaps temporarily renamed if that helps, and cutting out the bits you don't want and adding the bits you do (out of a working setup).

Alternatively, you could use the remaster method I described in my last post. Since the things you want to remove are in pup_215.sfs and not in your pup_save.2fs, you can use a new pup_save whilst doing this - no need to alter your existing pup_save.2fs at all (just keep it backed up ready for using again once you are finished and have the remastered pup_215.sfs ready for use). The good thing about this second method is that you can test that your changes to pup_215.sfs are actually working (e.g. the new Seamonkey configuration) since you are doing it all on the live system. I can imagine ways of doing the first method similarly but its all getting a bit complicated to explain. If you list step by step what you plan to do, I could give an opinion more easily.

Let's face it, as long as you keep backups of your existing pup_215.sfs and pup_save.2fs file you can't go wrong! (I'm assuming you have a frugal install on your hard disk). That's what I do; half the time I'm not sure what is going to happen (!) but I just experiment until things work the way I want. Keep backups!!!

[miriam]

I can confirm that the new Seamonkey libraries do work with gxine.

When I installed the new Seamonkey I moved the original files to a backup location on another drive. That's probably the safest way to do it. I tend to do this in case anything goes wrong so I can put things back the way they were till I figure out how I wrecked it).

I purposely left most of the plugins out of my new Seamonkey install as some of them annoy me -- especially Flash, which slows down my machine terribly when it is overused on a page. (It astonishes me how many page designers seem unable to resist the temptation to scatter dozens of little Flash gadgets around their pages.)

[ecomoney]

I did a preliminary test this morning with promising results. I downloaded the installer from the link above to my "downloads" directory (outside the pup_save file on an ext2 partition) and ran it. This created a directory with virtually the same file structure as the /usr/lib/seamonkey1.0.8.I (crudely) unzipped the pup_215.sfs file and deletes the contents of the seamonkey1.0.8 directory under usr/lib, and copied into it the directories and files from the /mnt/home/downloads/seamonkey1.1.4 directory. A nasty hack but linux tends to be forgiving Ive found.

On starting the new mozilla, I found that going to help>version revealed I was running the new seamonkey. Ive been testing it today and can only find a few faults. It even copied over my theme settings!

When I click the mail icon and mozilla is already running, it asks me to select a user profile from a choice of "default" and "default user", neither of which work as they say they are both in use. Also, the buttons to post messages in facebook do nothing, I dont know why this fault occurs or how to remedy it, although I would suspect is applies to other sites too. Gxine seems to continue work no problem. Im going to try some further experimentations with it.

[ecomoney]

Ive done some more testing!

Several other sites exist where the buttons do not work, also, a new mozilla instance cannot be started if there is already one running (not just the mail part). Ive noticed a difference with the error.

I get the seamonkey user profiles manager window up, and in it I get a choice between

"default" - I get the message "Seamonkey cannot use the profile default, because the directory containing the profile cannot be found".

"Default User" - I get the message "Seamonkey cant use the profile "Default User" because it is in use

I want to persevere with this for one reason, and one reason only, and its a very good reason...


FLASH 9 DOESNT CRASH!!!!!!

...I think