Pale Moon x86-64 SSE2/AVX2

[Kris_88]

so you can continue your petty beef with MC. Freaking childish.

don't talk nonsense

[Moonchild]

Cooldown issued.

[Drugwash]

Just wanted to say that I tried in good faith to switch from the official build which no longer supports SSE-only CPUs to this third-party SSE2 build. Unfortunately, it can't work on my system due to library requirements that are too new for it.

My machine runs Linux Mint 19.2 (based on Ubuntu 18.04) by choice, and as such any advice on upgrading is moot. Current version of Nuck-TH builds require Glibc 2.38 while my system has 2.27. Most likely other libraries have similarly high requirements.

I'm not requesting for anything. Just stating a fact. Hopefully others running old systems would see this and know why it doesn't work for them either.

Hopefully in a few months I'll be able to get a large drive which would allow me to compile my own personalized build using GCC 7.5 and the existing toolchain. Until then I'll stick to the official 33.2.1.

Thank you Nuck-TH for trying to help.

[Pentium4User]

You are running an OS that doesn't receive security updates anymore. A rather bad idea. I dunno why the short resources of the developers here should be wasted for supporting such ancient operating systems.
Upgrading glibc is something I don't recommend because that will likely break other parts of the OS.

Can you please tell why you want to stick with that OS version?

Just my opinion about this, no affront.

[Drugwash]

Off-topic:
I know all there is to know about old OS and all. Not paranoid about security, it's a simple home computer, nothing sensible here.
There is PPA I added that provides updates for 18.04 but I only cherry-pick a few that shouldn't break anything. Not glibc, for sure.
Reasons for sticking to that version may not be many but it's the line I drew and won't cross. Don't wanna hijack the topic with that.

[Pentium4User]

Off-topic:
I know all there is to know about old OS and all. Not paranoid about security, it's a simple home computer, nothing sensible here.
There is PPA I added that provides updates for 18.04 but I only cherry-pick a few that shouldn't break anything. Not glibc, for sure.
Reasons for sticking to that version may not be many but it's the line I drew and won't cross. Don't wanna hijack the topic with that.

OK, so no real reasons for doing that.
Your computer, your choice. Although, I see no reason why the team should now release another build for ancient Linux operating systems.

[suzyne]

Off-topic:
In the context of this:

I'm not requesting for anything.

I am not sure if this is really needed?

I see no reason why the team should now release another build for ancient Linux operating systems.

I dunno why the short resources of the developers here should be wasted for supporting such ancient operating systems.

[back2themoon]

HTTP links (bottom of first post) don't seem to work at the moment ("server taking too long to respond"). FTP links open normally.

[Pentium4User]

HTTP links (bottom of first post) don't seem to work at the moment ("server taking too long to respond"). FTP links open normally.

There was a change in the firewall rules. IPv6 wasn't working for http/https and MC decided to only provide HTTPS in the end.

Those links need to be changed to https.

[back2themoon]

Good to know, thanks. And I was wondering whether HTTPS would be more appropriate, for that page specifically. Adding the s makes it fly again.

I happily use FTP too, but it seems that either my ISP is throttling it somehow (speeds are quite slower - confirmed it elsewhere, too), or the way that protocol works is not about prioritising speed.

[JayByrd]

I've successfully compiled an SSE2 build for Slackware linux. I based my build on the Khronosschoty SlackBuild linked to on the Contributed Builds page.

I updated the script myself, mainly to account for the fact that we no longer need an external copy of autoconf 2.13.

Here's the resulting .mozconfig if anyone is interested:

Code: Select all

mk_add_options MOZ_OBJDIR=/tmp/SBo/obj-palemoon
ac_add_options --enable-official-branding
ac_add_options --prefix=/usr
ac_add_options --libdir=/usr/lib64
ac_add_options --with-default-mozilla-five-home=/usr/lib64/palemoon-33.3.0
ac_add_options --x-libraries=/usr/lib64
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --disable-accessibility
ac_add_options --enable-strip
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
ac_add_options --enable-release
ac_add_options --enable-devtools
ac_add_options --enable-application=palemoon
ac_add_options --disable-crashreporter
ac_add_options --disable-updater
ac_add_options --disable-tests
ac_add_options --enable-jemalloc
ac_add_options --with-pthreads
ac_add_options --enable-optimize="-O2 -msse2 -mfpmath=sse"

[Mike_Walsh]

My machine runs Linux Mint 19.2 (based on Ubuntu 18.04) by choice, and as such any advice on upgrading is moot. Current version of Nuck-TH builds require Glibc 2.38 while my system has 2.27. Most likely other libraries have similarly high requirements.

Um.....ya sure that's not a typo, Drugwash?

I'm currently running Nuck-TH's SSE2 build, repacked in the 'portable' format that works best for us here in Puppyland. I've included a self-contained, 'encapsulated' build of glibc 2.28 (from Debian 'Buster'), and called via my custom launcher.....like so:-

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' Pale Moon browser
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/profile" 2> /dev/null
#
export LC_ALL=C
#
$HERE/glibc228/lib/ld-linux-x86-64.so.2 --library-path $HERE/glibc228/lib:$HERE/glibc228/usr/lib:$HERE/glibc228/libstdc++:/usr/X11R7/lib:$HERE "$HERE/palemoon64/palemoon" "$@" -profile "$HERE/profile"

It's running very sweetly so far.

@Pentium4User :-

This may perhaps come as a shock to you, but I know for a fact that there are a fair number of Linux users that - like Drugwash - run older operating systems by choice.......because they suit the older hardware they run, and just happen to be far smoother in operation.

Not everyone is obsessed with having the "newest", "best", most "up-to-date", "safest" and most "secure" OS ALL THE TIME, believe it or not. In 10 years + of using Puppy Linux, I've never yet had a single security "issue" of any sort.....and I run a real smorgasbord of Puppies, both old AND new.

And I'm pretty sure that most who do this - BY choice! - don't expect anyone to make special allowances for them. Just sayin'.....from personal experience as much as anything.

(BTW:- I regularly update the glibc in most of my Puppies. It's simple enough.....IF you know what you're doing).

(*shrug...*)


Mike.

[Drugwash]

Um.....ya sure that's not a typo, Drugwash?

Yep, pretty sure. But it doesn't matter, don't wanna stir still waters, and besides I got a working SSE2 build thanks to a kind user. Will see what future brings to the table.

[Mike_Walsh]

Um.....ya sure that's not a typo, Drugwash?

Yep, pretty sure. But it doesn't matter, don't wanna stir still waters, and besides I got a working SSE2 build thanks to a kind user. Will see what future brings to the table.

Mike.

[andyprough]

My machine runs Linux Mint 19.2 (based on Ubuntu 18.04) by choice, and as such any advice on upgrading is moot. Current version of Nuck-TH builds require Glibc 2.38 while my system has 2.27. Most likely other libraries have similarly high requirements.

Um.....ya sure that's not a typo, Drugwash?

I'm currently running Nuck-TH's SSE2 build, repacked in the 'portable' format that works best for us here in Puppyland. I've included a self-contained, 'encapsulated' build of glibc 2.28 (from Debian 'Buster')

You are right, Nuck-TH's SSE2 build requires glibc 2.28. Your use of the encapsulated glibc 2.28 is very cool! Another way is to build a glibc 2.27 capable version of Pale Moon in a vm of Ubuntu 18.04 using a free Ubuntu Pro subscription for its free security updates through 2028. Or the Freexian project is offering extended long-term support for Debian 9 through 2027, you could also set that up in a vm and build Pale Moon, that should give you glibc 2.24.

[Mike_Walsh]

@ andyprough :-

Your use of the encapsulated glibc 2.28 is very cool!

Heh.Well, I have 'encapsulated' builds of glibcs

2.23
2.27
2.28
2.31
2.34, and
2.36

....most in both architectures.

One of our senior Puppy members demonstrated the ability to do this with browsers several years ago. I thought it was a really neat idea, and have built several, as listed above.

The biggest benefit here was being able to run up-to-date browsers in older Puppies that never had a sufficiently new enough glibc to be able to run these natively......and while I know we're a crazy bunch here in Puppyland ( ), many Puppians like to run much older, fully-kitted out and still-working Puppies; more for the "nostalgia" value than anything else. At least this way, they can have a decent, modern browser.

It's honestly simpler to do this than it is to rebuild the Puppy, because a lot of other stuff also needs upgrading, too, if you take this route.....on top of which, there's a very real risk of bricking things permanently IF you don't know what you're doing. We're harking back here to the early days of broadband AND, I believe, the very early years of Pale Moon itself, when many Puppians were still on dial-up AND restricted data plans. It was less painful for them to download a browser than it was an entire OS..!

It also means it doesn't interfere with the native glibc. It only gets used BY the 'portable' browser itself (you may be aware that I re-package Pale Moon into this format for the Puppy Linux community, because it just works better with Puppy's somewhat oddball approach to things). My portable is a little bit different to this community's version.....but not by much. It's just tweaked a bit to suit Puppy.

Oh; and it also keeps it outside the Puppy 'save-file'....which keeps the latter small and neat (almost an obsession with some Puppians!) Quite a number run it from a flash-drive, which IS kinda what I had in mind when we first started playing around with the whole idea of 'portable' browsers....since when I've assembled an entire range of portable browsers, both 'zilla-based & Chromium-based.

===============================

To be fair, it's a bit of a "hack" really (although the concept, apparently, goes all the way back to the swan-song of NetScape Navigator itself, believe it or not....in the very early years of the century), but it gets the browser up-and-running, & it appears to be fully-functional. This workaround will function for ANY 'zilla-based browser. But it won't work for Chromium-based browsers.....summat to do with Firefox/Pale Moon et al starting from a binary, whereas in Chromium & the 'clones' (as I call 'em!), you have to use a 'wrapper'-script to 'point' you at the large shared library that forms the bulk of the browser itself.

A binary is an ELF executable. An executable 'wrapper'-script, however, is NOT. I really don't understand where the difference lies, but...."me no expert". I've tried for years to get the glibc 'workaround' functional with the 'clones'.

Doesn't want to know. And I'm not THAT much of a geek! I'm a 'bumbler', messing around with concepts/ideas, playing around with scripts, frequently surprising myself when I DO actually manage to make summat work.....

(I know, I know; I'm too self-deprecating for my own good. It's always been a failing of mine. I'm probably nowhere near as useless as I like to make out.... )

I could detail some of my nutso projects over the last 3-4 years - which work, amazingly! - but I think I'd bore you to tears! So I'll quit yapping, and be ....

(*shrug...*)


Mike.