Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 25 Oct 2014, 12:45
All times are UTC - 4
 Forum index » House Training » HOWTO ( Solutions )
upgrading Seamonkey 1.0.8 to 1.1.4
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 2 Posts_count   Goto page: 1, 2 Next
Author Message
miriam


Joined: 06 Dec 2006
Posts: 281
Location: Queensland, Australia

PostPosted: Sat 08 Sep 2007, 11:39    Post_subject:  upgrading Seamonkey 1.0.8 to 1.1.4  

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:
#!/bin/sh
#exec mozstart "$@"
exec /usr/local/seamonkey/seamonkey "$@"

and
/usr/local/bin/defaultemail
script to be:
Code:
#!/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:
#!/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:
if [ -e /usr/lib/mozilla ];then
 LD_LIBRARY_PATH="/usr/lib/mozilla:$LD_LIBRARY_PATH"
fi

to
Code:
#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:
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:
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.

_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
miriam


Joined: 06 Dec 2006
Posts: 281
Location: Queensland, Australia

PostPosted: Sun 09 Sep 2007, 22:31    Post_subject:  

Updated with a better method to make the library path available to other programs like gxine. See above.
_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
ecomoney


Joined: 25 Nov 2005
Posts: 2183
Location: Lincolnshire, England

PostPosted: Tue 11 Sep 2007, 22:02    Post_subject: Update  

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.
_________________
Puppy Linux's Mission

Sorry, my server is down atm!
Back to top
View user's profile Send_private_message Visit_website MSNM 
Bruce B


Joined: 18 May 2005
Posts: 11130
Location: The Peoples Republic of California

PostPosted: Wed 12 Sep 2007, 16:59    Post_subject: Re: Update  

ecomoney wrote:
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.
Back to top
View user's profile Send_private_message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Wed 12 Sep 2007, 20:35    Post_subject: Re: Update  

Bruce B wrote:
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.
Back to top
View user's profile Send_private_message Visit_website 
Bruce B


Joined: 18 May 2005
Posts: 11130
Location: The Peoples Republic of California

PostPosted: Fri 14 Sep 2007, 13:33    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
Bruce B


Joined: 18 May 2005
Posts: 11130
Location: The Peoples Republic of California

PostPosted: Fri 14 Sep 2007, 13:35    Post_subject: Re: Update  

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.
Back to top
View user's profile Send_private_message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Fri 14 Sep 2007, 16:07    Post_subject: Re: Update  

1.
Bruce B wrote:
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

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


Bruce B wrote:
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/howpuppyworks.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.

Bruce B wrote:
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.
mcewanw wrote:
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.
Back to top
View user's profile Send_private_message Visit_website 
Bruce B


Joined: 18 May 2005
Posts: 11130
Location: The Peoples Republic of California

PostPosted: Sun 16 Sep 2007, 14:27    Post_subject: Re: Update  

mcewanw wrote:
1.
Bruce B wrote:
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.
Back to top
View user's profile Send_private_message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sun 16 Sep 2007, 19:25    Post_subject: Re: Update  

Bruce B wrote:
mcewanw wrote:
1.
Bruce B wrote:
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.

Edited_times_total
Back to top
View user's profile Send_private_message Visit_website 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sun 16 Sep 2007, 20:15    Post_subject: Consider me a bit of a bot  

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.
Back to top
View user's profile Send_private_message Visit_website 
Bruce B


Joined: 18 May 2005
Posts: 11130
Location: The Peoples Republic of California

PostPosted: Tue 18 Sep 2007, 01:00    Post_subject:  

Sorry, really.

I guess I misunderstood.
Back to top
View user's profile Send_private_message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Tue 18 Sep 2007, 02:56    Post_subject:  

that's ok.
Back to top
View user's profile Send_private_message Visit_website 
ecomoney


Joined: 25 Nov 2005
Posts: 2183
Location: Lincolnshire, England

PostPosted: Tue 18 Sep 2007, 05:21    Post_subject: Upgrading the .sfs  

Popular saying in professional IT circles

Quote:
"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?

_________________
Puppy Linux's Mission

Sorry, my server is down atm!
Back to top
View user's profile Send_private_message Visit_website MSNM 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Wed 19 Sep 2007, 05:43    Post_subject: Re: Upgrading the .sfs  

ecomoney wrote:
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:

ecomoney wrote:
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... Smile
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 1 of 2 Posts_count   Goto page: 1, 2 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » House Training » HOWTO ( Solutions )
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1774s ][ Queries: 11 (0.0509s) ][ GZIP on ]