MozillaZine

M11 for Sun Solaris 2.7 SPARC Available

Wednesday November 17th, 1999

While not an official release, Roland Mainz has cobbled together an M11 build for Solaris 2.7 SPARC. Thanks, Roland!

#1 M11 for *OS

by megaloB

Wednesday November 17th, 1999 9:46 PM

I think there should be yet another mozilla contest. something along the lines of "whomever ports the most mozillas shalt win something good." The last BeOS port was M8, and mozilla has improved in many leaps and bounds by this time. And there's probably people who would kill or die to use a current build/release of mozilla on BeOS. There's a plethora of others that could find themselves using mozilla, besides the 9x/Mac/*nix crowd. These three OS'es do constitute for a majority of the market share, but that doesn't mean other OS'es shouldn't enjoy the fruits of mozilla's labor.

I don't know if this would be an easy task or not (since it's not being done crazily now I'm guessing it's muy dificil), but it is food for thought.

#2 M11 for *OS

by Tekhir

Wednesday November 17th, 1999 11:16 PM

I'm ready to kill. Just point me to who.

-- Be user stuck in Windows

#3 librt.so

by Anon

Thursday November 18th, 1999 2:25 AM

It tells me that can't load librt.so :)

I have:

SunOS elisa 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-5_10

#5 Does not with with Solaris < 2.7 / was: librt.s

by Anon

Thursday November 18th, 1999 7:14 AM

(Roland Mainz:) The build system is my personal workstation which runns under Solaris 2.7. I would need a free machine to set up Solaris 2.6 (or better: Solaris 2.5.1) to make compilations for all - but I don't have one except an old SPARC SLC with 16 MB RAM :-(

#4 WARNING!

by Anon

Thursday November 18th, 1999 2:27 AM

This thing can LEAK LIKE CRAZY! I have a process that is now (get this) 749MB. Scary! Some days 512MB RAM help.

This might be due to my prodding the DOM viewer, of course.

This Mozilla build is pretty stable -- it has not crashed yet (big :-), which might be the thing that shows up the leakage -- but it **is** growing like Topsy.

Cheers,

N.

#6 WARNING!

by Anon

Thursday November 18th, 1999 7:17 AM

Roland Mainz: 1. There's the boehm collector for detecting leakage (but I didn't enable it in my build) 2. Where's your problem ? All our sun4u machines have 2GB swap or more =:-)

#9 WARNING! :-)

by Anon

Friday November 19th, 1999 7:41 AM

Neil Corlett: well, actually, i have that amount of swap :). but the paging knocks the performance in the end. i noticed because of the disk rattle noises.

it would be interesting to compare a Boehm build to this one, if only to see just how much collection the thing is actually doing.

Cheers,

N.

#7 Mozilla and Active X

by Anon

Thursday November 18th, 1999 10:14 AM

Okay... don't shoot me here... but I want to know if there is any group out looking at or implementing active x support in Mozilla, or in the Netscape equivelent? I understand all of the hazards behind active x, why it shouldn't be used, etc. However, it is. Especially in many "behind the firewall" situations. So... it would be nice if Mozilla did support Active X somehow (plug-in, native, I don't care). If I've missed this as an earlier feature, I apologize. Any info, greatly appreciated. Thanks!-bb

#10 There are Plugins

by Tekhir

Saturday November 20th, 1999 5:11 PM

From what I'm hearing the a lot of old $.x plugins work for Mozilla. Netscape 4.x has a plugin for ActiveX. I believe it is not free, but I haven't checked in a while.

If a very detailed sandbox can be built around the ActiveX, Java and JavaScript engines then I don't see a problem in having them.

#8 Mirrors/ M11 for Sun Solaris 2.7 SPARC Available

by Anon

Thursday November 18th, 1999 12:00 PM

(Roland Mainz:) ftp.mozilla.org has mirrored my build, see ftp://ftp.mozilla.org/pub/mozilla/releases/m11/mozilla-sparc-sun-solaris2.7-M11.tar.gz

#11 Active X cannot be secure...

by Anon

Saturday November 20th, 1999 6:33 PM

You cannot build a box nor a secure box around ActiveX, you'll need a x86 interpreter for this. Most ActiveX plugins are executing native x86 code, and this code can do anything... :-(