SeaMonkey 1.1.19 static builds

[DMcCunney]

As mentioned in this thread, Philippe Martinez in France has been creating and hosting static builds on SeaMonkey products.

On March 16th, the SeaMonkey project announced that support was being dropped for the SeaMonkey 1.1 branch. A 1.1.19 release was available that would be the end-of-life release for SeaMonkey 1.1. The announcement is here: http://www.seamonkey-project.org/news#2010-03-16

Philippe has now completed static Linux builds of both the browser only and full suite versions of SeaMonkey 1.1.19 in Gtk1 and Gtk2 versions.

Browser only:

Gtk1: http://www.lamarelle.org/seamonkey/1.1. ... 57.tar.bz2

Gtk2: http://www.lamarelle.org/seamonkey/1.1. ... 06.tar.bz2

Full Suite:

Gtk1: http://www.lamarelle.org/seamonkey/1.1. ... 44.tar.bz2

Gtk2 http://www.lamarelle.org/seamonkey/1.1. ... 33.tar.bz2

He has various Firefox and SeaMonkey 2.X builds available as well. See the main page here: http://www.lamarelle.org/mo-zi-lla/mozilla.php

(It is not possible to build Firefox 3.X or SeaMonkey 2.X static.)

Drop him a note on his site if you grab this stuff to say thanks: http://www.lamarelle.org/lammail.php
______
Dennis

[Béèm]

What is wrong with the one on SeaMonkey's site?

[DMcCunney]

What is wrong with the one on SeaMonkey's site?

Nothing, if you want a dynamic build.

Static builds tend to load faster on the sort of kit Puppy is run on.
______
Dennis

[Colonel Panic]

I may get this one if I can spare the download time. I've got Philiippe's 2.0.3 and 1.1.18 static builds already (for which, thanks for the link btw). I'm using them both, one in Puppy and the other in Vector, and they work great.

[Béèm]

What is wrong with the one on SeaMonkey's site?

Nothing, if you want a dynamic build.

Static builds tend to load faster on the sort of kit Puppy is run on.
______
Dennis

Thank you for the explanation.
Still a bit confused as wiki pages speak about advantages for one method and other advantages for the other.

So as I understand my situation, I am in the dynamic situation. Up to know I haven't found any ill effects.

I didn't look into comparison of loading time.

[DMcCunney]

What is wrong with the one on SeaMonkey's site?

Nothing, if you want a dynamic build.

Static builds tend to load faster on the sort of kit Puppy is run on.

Thank you for the explanation.
Still a bit confused as wiki pages speak about advantages for one method and other advantages for the other.

So as I understand my situation, I am in the dynamic situation. Up to know I haven't found any ill effects.

I didn't look into comparison of loading time.

You shouldn't see ill effects.

Linux applications almost all use code in libraries. A lot of code is common to more than one application, so rather than compile the code into each application that uses it, the code will be stored in an external library file, and shared by any program that needs it. When the program in compiled, instructions to the compiler tell it "look in the following list of external libraries for any routines referred to in the code that aren't defined in the code." Shared libraries in Linux have .so extensions, and normally live in /lib or /usr/lib, but don't have to. The program may install its own libraries in its own directory. (Windows also uses libraries, in the form of DLL files)

Code compiled this way is "dynamically" built. When the program is run on the user's machine, it looks for and links against the external library files that were specified when it was built to find the missing pieces. If it can't find the libraries, or the libraries are the wrong versions and don't contain the routines required, the program will fail to run, with an error message like "foo: error resolving symbol in libbar.so". This usually means that "libbar.so" doesn't exist on the user's machine.

Code built "static" is done by compiler directives that tell it "look in the following list of external libraries for any routines referred to in the code that aren't defined in the code, and when you find them, extract them from the libraries and include them in the executable." Programs built static tend to be a lot larger than dynamically built programs, because they include code that would ordinarily be called from external libraries.

But static executables tend to load faster on lower end gear. Loading the program is often just a matter of finding the start of program in the file system, and doing a continuous read till it's in RAM and ready to execute. The program contains everything required, and doesn't have to find and link against internal files.

When a program is dynamically built, the program must be loaded, and any external libraries it links against must be found, opened, and the routines used by the program located, before the program is ready to run.

I have Opera 10.10 and Firefox 3.6 installed here. Opera is a static build. Firefox is dynamic. They are about the same total size, but Opera loads about twice as fast as Firefox. Opera is one big executable and one smaller external library. Firefox is one small executable and a number of large external libraries. As far as I can tell, I'm getting clobbered by the disk I/O required to locate and link against the external libraries when FF is run.

The Puppy box has 256MB RAM and a slow UDMA 4 HD with an 18mb/sec transfer rate. Moving to an ext4 file system when I installed Puppy 4.31 helped, and I saw a 25% - 30% improvement in disk throughput, but it still isn't what I'd call fast.

If you have a faster and more powerful machine, the difference between a dynamic and a static build will be less noticeable. You shouldn't see any difference once the program is up and running in any case. The difference will be how fast it loads and is ready to run.
______
Dennis

[Béèm]

Thank you Dennis McCunney, you filled in the holes not clearly covered in the Wiki. I have a better idea now.
As well SeaMonkey 2.0.3 as well OpenOffice, both installed outside the pup save environment have .so files, so libraries, in their directory structure.
For SeaMonkey I know I had to copy libraries to /lib for it to run correctly.

My laptop has 256MB as well, but for my frugal install I have to use a swap file as OOo gives problems without it.

So your machine is a full install on ext4 then?

[technosaurus]

Dennis's explanation is great for the "normal" way of doing things, but mozilla also has 2 different "static" and 2 different "shared" build methods.

For mozilla, the traditional completely static build requires an additional paramater at build time, otherwise it only builds its own internal libraries as static while linking with shared system libraries, thus making it both smaller and faster - the only issue is that gtkmozembed and Puppy Browser require some of those libs to be shared (or they would need to be compiled against the static libs as well). One could argue that these mini-browsers wouldn't be needed if FF/SM were smaller and faster, but I digress.

On the dynamic side "there is no data there is only XUL" is another ghostbuster's ripoff referring to libxul, which is a single shared library that takes the place of many separate shared libraries - this is now mozilla's "preferred" distribution method, with the hopes that eventually all mozilla apps can share the same base libXUL(however after 3 years progress is still insufficient) Having a single library containing all of the objects reduces some of the I/O that Dennis referred to. On the other hand having individual shared libraries makes it easier to do security patches without updating the whole system (however I don't know any distro that actually does this)


... By the way doing a static build of seamonkey takes roughly twice as long due to all of the link time optimizations across all of the different libraries and is heavily dependent on having lots of RAM. When compiling static libs that will only be used in a binary there are several flags that will reduce the size and increase the speed that usually have to be hacked in due to their "rare" useage (aka not win32 compatible):
-fno-pic and -fno-PIC to replace -fpic and -fPIC

-ffunction-sections -fdata-sections and -Wl,--gc-sections

and usually:
-fweb -Wl,-relax -fmerge-all-constants -momit-leaf-frame-pointer -fomit-frame-pointer
(see the documentation at gcc.gnu.org for more details)
to speed up load times -Wl,--as-needed
... and if you are building a fixed system that will contain all the same system shared libraries in the same location you can prelink them with -Wl,-z,now ... so that this doesn't need to be done at startup (see what happens to startup times if you change a library though)

[Béèm]

Thank you technosaurus for that supplementary explanation.
A lot of technical details, I didn't know.

But I am happy I found the way to install applications like SeaMonkey, FireFox, OOo on a place outside the save file by downloading and extracting the tar files (except OOo which are rpm's)

These app's are available now directly to all puppies I install.

I also took the .wine outside the pup save for the same reason and symlink it.

So also wine applications can be accessed by all puppies booted.
(Being in frugal I use a wine sfs)

[DMcCunney]

Thank you Dennis McCunney, you filled in the holes not clearly covered in the Wiki. I have a better idea now.
As well SeaMonkey 2.0.3 as well OpenOffice, both installed outside the pup save environment have .so files, so libraries, in their directory structure.
For SeaMonkey I know I had to copy libraries to /lib for it to run correctly.

You could probably put them in /usr/lib, instead. What matters is that the system can find them.

My laptop has 256MB as well, but for my frugal install I have to use a swap file as OOo gives problems without it.

So your machine is a full install on ext4 then?

Correct. I triple boot Win2K Pro, Ubuntu 9.10, and Puppy 4.31. Ubuntu and Puppy are both installed on ext4 file systems, and can see each other's partitions. (Puppy mounts the Ubuntu partition as /media/ubuntu on startup, to make getting at stuff in it easier.)

I have a 512MB swap partition that is used by both Puppy and Ubuntu.

I prefer full installs. Frugal installs don't offer advantages to me, and performance is better overall with a full install. On a bigger, faster machine, or if I was playing with multiple Puppy versions and configurations, that might differ. (But on a bigger, faster machine, I probably wouldn't run Puppy. I got Puppy as a distro suited to lower end gear, which the Lifebook is. If I have the hardware to run something more mainstream, I do so. My Windoze desktop with a 2ghx CPU, 4GB of RAM and multiple UDMA 5 and 6 HDs triple boots Win2K Pro, WonXP Pro, and Ubuntu 9.10.)

[DMcCunney]

Dennis's explanation is great for the "normal" way of doing things, but mozilla also has 2 different "static" and 2 different "shared" build methods.

For mozilla, the traditional completely static build requires an additional paramater at build time, otherwise it only builds its own internal libraries as static while linking with shared system libraries, thus making it both smaller and faster - the only issue is that gtkmozembed and Puppy Browser require some of those libs to be shared (or they would need to be compiled against the static libs as well). One could argue that these mini-browsers wouldn't be needed if FF/SM were smaller and faster, but I digress.

I wish they were, but don't see it happening. I still use a static build of SM 1.1.19 for the minimal browsing I do from Puppy because FF 3.6 is simply too big and slow, and SM 2.04 isn't a lot better. FF, for example, takes 30 seconds or more simply to load, and is sluggish when up.

Barry is apparently shifting to SM 2 for future Puppy development. I'll be curious to see how that works.

On the dynamic side "there is no data there is only XUL" is another ghostbuster's ripoff referring to libxul, which is a single shared library that takes the place of many separate shared libraries - this is now mozilla's "preferred" distribution method, with the hopes that eventually all mozilla apps can share the same base libXUL(however after 3 years progress is still insufficient) Having a single library containing all of the objects reduces some of the I/O that Dennis referred to. On the other hand having individual shared libraries makes it easier to do security patches without updating the whole system (however I don't know any distro that actually does this)

Mozilla's longer term goal is to separate out the Gecko engine as a separate stand-alone package, with FF, TB et al simply instances of things it renders. So down the road, browser, email client and the like won't need copies of Gecko bundled with them. There will be one, shared by apps that use it.

This offers possibilities. We're already seeing apps like the Songbird media player and the ActiveState Komodo programmer's IDE using Gecko for rendering. No good reason why you couldn't implement a desktop in XUL...
______
Dennis

[Colonel Panic]

Thank you Dennis McCunney, you filled in the holes not clearly covered in the Wiki. I have a better idea now.
As well SeaMonkey 2.0.3 as well OpenOffice, both installed outside the pup save environment have .so files, so libraries, in their directory structure.
For SeaMonkey I know I had to copy libraries to /lib for it to run correctly.

You could probably put them in /usr/lib, instead. What matters is that the system can find them.

My laptop has 256MB as well, but for my frugal install I have to use a swap file as OOo gives problems without it.

So your machine is a full install on ext4 then?

Correct. I triple boot Win2K Pro, Ubuntu 9.10, and Puppy 4.31. Ubuntu and Puppy are both installed on ext4 file systems, and can see each other's partitions. (Puppy mounts the Ubuntu partition as /media/ubuntu on startup, to make getting at stuff in it easier.)

I have a 512MB swap partition that is used by both Puppy and Ubuntu.

I prefer full installs. Frugal installs don't offer advantages to me, and performance is better overall with a full install. On a bigger, faster machine, or if I was playing with multiple Puppy versions and configurations, that might differ. (But on a bigger, faster machine, I probably wouldn't run Puppy. I got Puppy as a distro suited to lower end gear, which the Lifebook is. If I have the hardware to run something more mainstream, I do so. My Windoze desktop with a 2ghx CPU, 4GB of RAM and multiple UDMA 5 and 6 HDs triple boots Win2K Pro, WonXP Pro, and Ubuntu 9.10.)

Good post Dennis. Frugal vs. full installs; I found the problem with a full install is that when you break XOrg and can't get it back, you've essentially got a useless installation and have to start again. With a frugal install you only have to delete the savefile and create a new one, and the smart thing to do is have a spare one as backup.

[DMcCunney]

Good post Dennis. Frugal vs. full installs; I found the problem with a full install is that when you break XOrg and can't get it back, you've essentially got a useless installation and have to start again. With a frugal install you only have to delete the savefile and create a new one, and the smart thing to do is have a spare one as backup.

I haven't broken Xorg in some time, but I believe I could get it back from the command line by diddling xorg.conf.

In a case of serendipity, I'm currently wrestling with Ubuntu. I upgraded to Ubuntu 10.4 beta on the Puppy machine. The upgrade went fine, but the video mode is now 1024x768 instead of the native 1280x768 the onboard ATI video can do. Ubuntu 10.4 doesn't seem to use xorg.conf, but I haven't found where it does keep those settings. Lots of Ubuntu info out there, but all either referring to older versions, or doing things from Gnome, when I normally use either Xfce4 or Lxde. (Installing Lxde added it as a choice of session environment on the Login screen, so I can use Xfce4, Lxde, Openbox, or a command line session in an Xterm. Sweet.)
______
Dennis

[DaveS]

When I first switched to Linux, like so many, on advice from others, I went with Ubuntu. Fine distro. I had it up and running in an hour or so, and then began the steep learning curve that is Linux. In time, curiosity and to some extent, bloody mindedness, led me to Puppy. I have been with Puppy for a couple of years now, and every time I re-try Ubuntu, I like it a bit less. It is something to do with all the automation. Somehow, I feel less involved, less satisfied.
In terms of productivity, I suspect it is easier to configure Puppy EXACTLY the way you need it. It takes a little learning, but so does everything worthwhile.
This is not meant as a snipe at Ubuntu, rather just the ramblings of a silly old s*d who is a bit bored

[Colonel Panic]

Good post Dennis. Frugal vs. full installs; I found the problem with a full install is that when you break XOrg and can't get it back, you've essentially got a useless installation and have to start again. With a frugal install you only have to delete the savefile and create a new one, and the smart thing to do is have a spare one as backup.

I haven't broken Xorg in some time, but I believe I could get it back from the command line by diddling xorg.conf.

In a case of serendipity, I'm currently wrestling with Ubuntu. I upgraded to Ubuntu 10.4 beta on the Puppy machine. The upgrade went fine, but the video mode is now 1024x768 instead of the native 1280x768 the onboard ATI video can do. Ubuntu 10.4 doesn't seem to use xorg.conf, but I haven't found where it does keep those settings. Lots of Ubuntu info out there, but all either referring to older versions, or doing things from Gnome, when I normally use either Xfce4 or Lxde. (Installing Lxde added it as a choice of session environment on the Login screen, so I can use Xfce4, Lxde, Openbox, or a command line session in an Xterm. Sweet.)
______
Dennis

Good post Dennis. Have you tried Linux Mint? It's based on Ubuntu but has drivers for older video cards than Ubuntu has and all the media codecs which Ubuntu doesn't.

It also still actively supports dialup, one of the few distros (along with Puppy of course) which still does, which is to be honest why I like it more than Ubuntu (and most other distros too). However, like Ubuntu it uses a lot of resources compared to Puppy.