Veit Kannegieser's repo

[Night Wing]

I had some problems to understand what SSE and AVX is and was not sure if I have gtk2 or gtk3.

Left click on "Help" > "About Pale Moon" and when the windows opens up, it will show you what version of Pale Moon you are using as well as what GTK version you are using.

[Veit Kannegieser]

Usually gtk2 is only required if you're going to use any NPAPI plugins, as far as I know.

Just tried mozplugger with GTK3 variant, and it still works.

Bildschirmfoto_2024-12-16_23-03-41.png

i saw only differences like a blue frame around the address bar when active.

[Moonchild]

Usually gtk2 is only required if you're going to use any NPAPI plugins, as far as I know.

No, it's a bit more complex than that.

See: viewtopic.php?f=62&t=30781&p=247897#p247897

[__NM64__]

Would it be possible for Pale Moon's built-in update notification to still function? I understand that it wouldn't have the ability to actually install updates straight from the program (unless you were running as root presumably), but wouldn't the "Check for updates" selection still be possible? I really like having that ability without needing to rely on email notifications (what I've been doing up to this point).

This is the message I currently get in Pale Moon with it set to "Check for updates":

screenshot.png

...also I can't help but notice that, when I upgraded directly from Steve Pusser's builds, the update setting defaulted to "automatic updates" which seemed a bit odd considering that, as I stated, this shouldn't actually even function.

And since it's more relevant to this thread, I'm quoting a protip I posted in the thread for Steve Pusser's builds:

protip: the gtk3 builds are treated as an upgrade over the gtk2 builds even of the same given versions. So if you have no qualms of gtk2 vs gtk3, then you can use the gtk2 build as your day-to-day version and then switch over to gtk3 if you need or want to change which build you're using without waiting for the next Pale Moon update (this is particularly useful if you take advantage of the fact that Linux is way less picky about being installed to a single given PC, i.e. you can boot a given OS installation on all kinds of different PC hardware configurations without issue...at least if it's just AMD or Intel since Nvidia is hit-and-miss )

Using my own real-life example, our "HTPC" uses a Ryzen 4500 but, due to a broken wire, I needed to temporarily decommission it. My stop-gap solution is a system with a Pentium G3258 (basically an overclockable Haswell i3 without hyperthreading) which of course, Intel loving segmentation, lacks AVX. So I was able to simply switch from the AVX(2) gtk2 build to the SSE2 gtk3 build via a standard apt update despite both having been v33.5.0.

[Veit Kannegieser]

Hello, __NM64__

Would it be possible for Pale Moon's built-in update notification to still function?

You would use the official palemoon-*.tar.xz package and install Pale Moon in your OS user profile.

This is the message I currently get in Pale Moon with it set to "Check for updates":

I recommend to disable the updater when using system wide install.

I can try to change the default value of app.update.enabled to false, which is what internally Steve Pusser's builds have (and the code+user interface removed).

For the "protip": that is a happy accident for '2' < '3' and 'a' < 's' in ASCII.

[__NM64__]

You would use the official palemoon-*.tar.xz package and install Pale Moon in your OS user profile.
...
I recommend to disable the updater when using system wide install.

I can try to change the default value of app.update.enabled to false, which is what internally Steve Pusser's builds have (and the code+user interface removed

Perhaps I wasn't clear.

As of right now, your builds have the three standard Pale Moon options for the internal updater:

• Automatically install updates
• Check for updates, but let me choose whether to install them
• Never check for updates

I fully understand that the "automatically install updates" function would not work in your builds and this is not what I want to do anyway - I prefer having updates handled by my OS's package manager.

However, I do like being notified of when Pale Moon specifically has an update available, so I have selected the "check for updates, but let me choose whether to install them" option instead (in fact this is what I used back when I was still using Windows 7 on my personal computer). My confusion is that, despite that setting specifically not installing updates automatically, it still presented me with the previously-mentioned error even without me having told it to update or anything.

Therefore, I was asking if this was a bug or something and/or if it were possible to make at least the "check for updates, but let me choose whether to install them" setting actually function with your builds? Again, I don't expect it to be able to install updates, but checking is not the same as installing as otherwise standard Pale Moon wouldn't have separate options in the first place for "automatically install updates" and "check for updates, but let me choose whether to install them"

[Nuck-TH]

Internal updater is not made for cases when application(Pale Moon/Basilisk/etc) is managed by system package manager period and must be disabled in build options. But since this packages uses binaries built by me, it is not done here, and updater must be set to not check for updates because package manager already does it.

So either deal with it or use standalone installation(look here for instructions to integrate it into system http://linux.palemoon.org/help/installation/) where updater will work as intended.

[__NM64__]

updater must be set to not check for updates because package manager already does it.

I can understand this being the case for installing updates, but I'm confused as to why this is the case for simply checking and/or notifying that updates exist?

EDIT: Also I realize that the built-in update notifier wouldn't be able to check for updates from Veit Kannegieser's repo, but I just mean checking for updates from the normal standard Pale Moon versions (especially since Veit Kannegieser's repo gets updated extremely quickly and there's minimal if any time lag relative to the normal standard Pale Moon versions).

[Veit Kannegieser]

The 33.5.1 DEBs are uploaded now, on the third attempt it now installs a /usr/lib/palemoon/browser/defaults/preferences/disable_updater.js, which has

Code: Select all

pref("app.update.enabled", false);

to disable the updater. Please ignore the user interface/settings that remain.

To get notification about updates, please subscribe to the announcements section of the forum, or use a service or extension like Update Alert on the release notes page.

The change the prevents the "Check for updates, but let me choose whether to install them" was done when protecting against running as root user.
If you want to revert that back, you would need to remove the file /usr/lib/palemoon/updates, after every update. I can not recommend that.

Please consider a different update notification, or install in you OS user profile, as linked by Nuck-TH.

[__NM64__]

For the "protip": that is a happy accident for '2' < '3' and 'a' < 's' in ASCII.

Oh, it seems the 'a' < 's' thing might be the actual reason because I can go from gtk2 avx(1) to gtk2 sse2, but I can't go from gtk2 avx(1) to gtk3 avx2.

Therefore I can't test going from avx2 until the next Pale Moon version or I remove the package altogether and install the avx2 package instead (and I'm not that concerned to try).

[Veit Kannegieser]

..or I remove the package altogether and install the avx2 package instead (and I'm not that concerned to try).

It is actually quite painless: adjust the apt packet configuration, and then do

Code: Select all

apt-get update
apt-get remove  palemoon
apt-get install palemoon

Would download ~37 MiB. The 'remove' part does not involve user profiles.

[__NM64__]

Didn't matter since Pale Moon 33.6.1 released so soon after that last post of mine that I hadn't even yet gotten back around to looking into this, and the Pale Moon update is what actually reminded me.

The good news is that it turns out you can go from avx2 gtk2 to avx(1) gtk2 (or avx2 gtk3 to avx(1) gtk3) without changing versions (e.g. remaining on 33.6.1 in my case), therefore there's actually very little reason to not just always use the avx2 build if your hardware can support it!

In other words, the user doesn't have to worry about being "stranded" on a build that doesn't support their hardware since you can always just subsequently "downgrade" to the avx(1) and/or sse2 build※ even in situations like mine where I like to boot a single Linux OS installation on completely different hardware.


※obviously this "downgrade" process won't work in situations with no internet connection, but surely you'd have internet access if you're trying to use a web browser like Pale Moon, right?


So the "upgrade" path available while maintaining a single version of Pale Moon can be summarized as the following:

• gtk2 ▶ gtk3 ▶ avx2 ▶ avx(1) ▶ sse2

The main takeaway is that the CPU SIMD takes priority in what apt determines to be an upgrade, meaning you can't use the gtk2 to gtk3 upgrade path to "upgrade" the CPU SIMD requirement - gtk3 is only considered an upgrade if the CPU SIMD is equal to or less than your current (so you can't go from sse2 gtk2 to avx2 gtk3).