Plans for Pale Moon for Linux 27

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
Skaendo
Moonbather
Moonbather
Posts: 51
Joined: 2016-02-28, 21:58

Re: Plans for Pale Moon for Linux 27

Unread post by Skaendo » 2016-09-21, 05:43

Would it be possible to coax the devs into using a distro that uses upgraded packages instead of patched ones?

CentOS might be great, but I believe that it is breaking compatibility in distros that are using newer packages than what CentOS delivers.

Or maybe publish some debugging symbols for those of us that do use upgraded packages.

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-09-21, 08:26

Which packages are you referring to?

If you are talking about comple environment prerequisites we have some hard dependencies such as exactly autoconf 2.13 or a specific range for gcc and whatnot.

If you are talking about system libs like libjpeg or say libvpx.. You shouldn't be using any system libs period because our glue for these various modules expect specific versions in-tree.

Also, exactly what beyond your belief can you present to substantiate your assumption.

Skaendo
Moonbather
Moonbather
Posts: 51
Joined: 2016-02-28, 21:58

Re: Plans for Pale Moon for Linux 27

Unread post by Skaendo » 2016-09-21, 11:05

NVM, I forgot you guys are smarter than the rest of us.

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-09-21, 11:28

Skaendo wrote:NVM, I forgot you guys are smarter than the rest of us.
Well if there is something going on it would only help us (and by extension you) to know.. So it can be evaluated and dealt with..

You can't just vaguely ask us to do something that may radically change how we do release engineering and our build environment without more information. Why should we not use CentOS or which packages should we be updating to? You provided no information just a sweeping theory based on an assumption.. We need more.

What distro would you prefer then? What packages are suspect? Where did this theory or belief originate from? We don't have the bandwidth or protocol to read people's minds.. yet anyway ;)

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Plans for Pale Moon for Linux 27

Unread post by Walter Dnes » 2016-09-21, 21:27

Agreed that we should be using Pale Moon's libs where possible, rather than system. But gcc and glib and mesa and gtk+-2.x and libXt have to come from the system. Will Pale Moon built on gcc 5.x run on a system/distro built on 4.9.x? And some people on the (b)leeding edge are on gcc 6 already. It may not be possible to align one build to fit every last corner case out there.

Maybe the best solution would be a "Build Your Own" (sub)forum for linux, for people who need help doing their first build. It's a bit of a learning curve, but I managed it, so most users should be able to. "Build your own, but you're on your own. If it breaks, you get to keep the pieces, etc." This would cut down the requests for contributed builds and special versions. It'll also squeeze out more performance for people who build with "-march=native".
There's a right way
There's a wrong way
And then there's my way

half-moon

Re: Plans for Pale Moon for Linux 27

Unread post by half-moon » 2016-09-22, 01:08

Building Pale Moon takes up a lot of system resources, and people may not have the resources for that.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Plans for Pale Moon for Linux 27

Unread post by Walter Dnes » 2016-09-22, 02:33

half-moon wrote:Building Pale Moon takes up a lot of system resources, and people may not have the resources for that.
I did it on an ancient 32-bit-only Atom netbook with 2 gigs of ram... once. It actually built... in approximately 11 hours. :thumbdown: People whose only computer is an underpowered single-core-cpu unit, will have to rely on the mainline build or contributed builds, or a neighbour with a better computer.

With an Intel Core2, 3 gigabytes of ram, manufactured in 2008, I was doing native builds in 90 minutes. That's approximately what it take me now to build Tycho on an i6 (Ivybridge) desktop, in a QEMU virtual machine, with 3 gigs of ram, and 3 of my 4 cores allocated to the VM. Note that I do not run X in the VM while the build is in progress.
There's a right way
There's a wrong way
And then there's my way

User avatar
ketmar
Lunatic
Lunatic
Posts: 369
Joined: 2015-07-28, 11:10
Location: Earth

Re: Plans for Pale Moon for Linux 27

Unread post by ketmar » 2016-09-22, 02:40

just to add some non-sensical numbers: v26 build on i3 with 4GB of RAM, using all 4 cores (but not exclusively: there is videoplayer running, Pale Moon itself, etc.) -- ~40 minutes.

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-09-22, 02:57

Just because you CAN build and get away with less than recommended resources does not mean the build is any good or that you did it correctly.. I am not going to rehash this again with you guys.

I want to hear from Skaendo about his potential issues he has found. THAT is the current topic for discussion in this thread.

half-moon

Re: Plans for Pale Moon for Linux 27

Unread post by half-moon » 2016-09-22, 11:35

ketmar wrote:just to add some non-sensical numbers: v26 build on i3 with 4GB of RAM, using all 4 cores (but not exclusively: there is videoplayer running, Pale Moon itself, etc.) -- ~40 minutes.
Umm, an i3 has only two cores.

User avatar
ketmar
Lunatic
Lunatic
Posts: 369
Joined: 2015-07-28, 11:10
Location: Earth

Re: Plans for Pale Moon for Linux 27

Unread post by ketmar » 2016-09-22, 18:20

half-moon wrote:
ketmar wrote:just to add some non-sensical numbers: v26 build on i3 with 4GB of RAM, using all 4 cores (but not exclusively: there is videoplayer running, Pale Moon itself, etc.) -- ~40 minutes.
Umm, an i3 has only two cores.
it is hyperthreaded. for the sake of building from sources we can assume that we have full 4 cores.

Skaendo
Moonbather
Moonbather
Posts: 51
Joined: 2016-02-28, 21:58

Re: Plans for Pale Moon for Linux 27

Unread post by Skaendo » 2016-09-22, 19:27

Matt A Tobin wrote:I want to hear from Skaendo about his potential issues he has found. THAT is the current topic for discussion in this thread.
Just an example:
How about using a distro that uses a glibc package that is newer than 2.17? glibc-2.17 was released pre 08-12-2013 (and that was 2.18).
According to distrowatch, and the CentOS package repo, CentOS 7 comes with glibc-2.17 that has been patched 100+ times.

Sooner or later you are going to run into problems with distros that are using updated packages and you are still developing on an archaic distro.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Plans for Pale Moon for Linux 27

Unread post by Walter Dnes » 2016-09-23, 02:31

Skaendo wrote:Sooner or later you are going to run into problems with distros that are using updated packages and you are still developing on an archaic distro.
The Windows build seems to support Windows 7 (released 2nd half 2009) through 10. Is linux less backwards-compatable over the years?

Assuming that it is a problem, it'll come down to which group of users to build for. I assume that the devs want to get the maximum possible audience, and that they don't really want to build 2 or 3 linux versions for different glibc versions. Oh yeah... 32 and 64 bit versions too. This is where roll-your-own or contributed builds would help.

Unless there is a major, unpatchable, security bug that forces the rapid abandonment of older glibc versions, users of the "latest+greatest" version will be a minority of linux users for a while. So it would make sense to target the older versions, until their numbers decrease significantly. Roll-your-own or contributed builds would serve users of the newest libs. Gentoo stable is currently at glibc-2.22-r4.
There's a right way
There's a wrong way
And then there's my way

Skaendo
Moonbather
Moonbather
Posts: 51
Joined: 2016-02-28, 21:58

Re: Plans for Pale Moon for Linux 27

Unread post by Skaendo » 2016-09-23, 04:47

Walter Dnes wrote:
Skaendo wrote:Sooner or later you are going to run into problems with distros that are using updated packages and you are still developing on an archaic distro.
The Windows build seems to support Windows 7 (released 2nd half 2009) through 10. Is linux less backwards-compatable over the years?

Assuming that it is a problem, it'll come down to which group of users to build for. I assume that the devs want to get the maximum possible audience, and that they don't really want to build 2 or 3 linux versions for different glibc versions. Oh yeah... 32 and 64 bit versions too. This is where roll-your-own or contributed builds would help.

Unless there is a major, unpatchable, security bug that forces the rapid abandonment of older glibc versions, users of the "latest+greatest" version will be a minority of linux users for a while. So it would make sense to target the older versions, until their numbers decrease significantly. Roll-your-own or contributed builds would serve users of the newest libs. Gentoo stable is currently at glibc-2.22-r4.
https://distrowatch.com/search.php?pkg= ... #pkgsearch

half-moon

Re: Plans for Pale Moon for Linux 27

Unread post by half-moon » 2016-09-23, 17:04

ketmar wrote:
half-moon wrote:
ketmar wrote:just to add some non-sensical numbers: v26 build on i3 with 4GB of RAM, using all 4 cores (but not exclusively: there is videoplayer running, Pale Moon itself, etc.) -- ~40 minutes.
Umm, an i3 has only two cores.
it is hyperthreaded. for the sake of building from sources we can assume that we have full 4 cores.
4 threads =/= 4 cores. Having a dual-core with 4 threads is far from the same thing as having 4 cores.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Plans for Pale Moon for Linux 27

Unread post by Walter Dnes » 2016-09-23, 17:23

The URL you pointed to has the statement...
The following distributions include glibc version greater or equal to 2.23 in the latest release:
By "latest", I assume they include the "unstable" branch. I am on the "stable" branch. I sync'd a few minutes ago to check, and the stable branch is currently at glibc-2.22-r4. "Unstable" is at glibc-2.23-r2. Yes it exists, but I would not call it representative of most Gentoo users. Then there's the always-experimental "9999" version which points at the git sources upstream. It's not for regular use.

Does Distrowatch also include Debian "testing" as a current release? If so, I have my doubts about their validity as an indicator of current usage of linux distro versions.
There's a right way
There's a wrong way
And then there's my way

CharmCityCrab

Re: Plans for Pale Moon for Linux 27

Unread post by CharmCityCrab » 2016-09-23, 23:10

Take this with a grain of salt. I'm not an expert, and I'm a Windows user (Though I've used Linux some in the past). So, I'm probably wrong. However, I saw a question raised that wasn't answered, and thought I'd take a (Likely inaccurate) stab at it.

Earlier in the thread, there was a question raised as to which distro would be the best for development and testing against.

I note that on DistroWatch, the top three distros by users are listed as being Mint, Debian, and Ubuntu. Ubuntu is a fork of Debian, and Mint is a fork of Ubuntu (normally) or Debian (special edition available to users who prefer it). Even lower down, I noticed that in the 7 and 8 positions (Elementary and Zorin) are two distros listed on the site as being in some way based on Debian and/or Ubuntu, and I would suspect I'd find more if I kept clicking around.

So, given that Mint, Ubuntu, and Debian are very similar "under the hood" and closely tied together, and are the three most popular distros, it seems to a lay person to make sense to concentrate development efforts on being broadly compatible with things in the .deb neighborhood, Linux wise.

Of course, if one had a browser that was specifically geared towards getting business IT departments to adopt it, given the penetration of Red Hat into the business world, CentOS (Which sticks close to Red Hat on delay and without the copyrighted components) would be the logical choice to develop for. My impression, though, is that Pale Moon primarily is going after home users and/or users who may use their computer for business purposes, but essentially home users in the sense of having control over their own device and aren't managing or subject to an IT department. Clearly, the Debian-derived distros are dominating desktop user share in general, and especially in the home user segment, I'd imagine.

However, that doesn't mean that CentOS is a bad environment to develop in and for. Maybe it's an easier distro to develop on in order to create the largest possible cross-compatibility or something, perhaps precisely because of the older packages it uses. I have no clue.

I noticed there is a guy doing an official Pale Moon for Ubuntu package in an "unofficial" (i.e. Not directly authorized or managed by Ubuntu) repository he hosts himself, and he describes being largely able to do it with somewhat automated software based on the generic tarball or whatever that Pale Moon puts out. So, developing on CentOS doesn't seem to really be hindering compatibility with the distros that are most popular, probably negating an impetus to abandon CentOS for them if the developer(s) are most comfortable using CentOS.

Really, I think the key thing I'd be looking at if I were involved with a browser trying to get more Linux users, is how to get the browser pre-installed as the default browser on some distros, and if not, how to get people to put in the official repositories and stores where it'll come up on top when users search for browsers other than Firefox and Chromium, with devs from the distros maintaining a compatible version optimized for their distros concurrent with each release from Pale Moon itself, the way they do with Firefox.

However, how much it's really possible to get that kind of placement and effort from the distroes, and, if it's possible, how one would go about it, and whether or not it's worth the time and resources that might be involved in making it happening- no clue.

But I do think it'd obviously be good for Pale Moon if somehow people installed Mint or Ubuntu or something and by default, Pale Moon was the web browser sitting on their desktop instead of Firefox. If Pale Moon were a corporate-backed project, I'd say try to buy that placement. Since it's not... I wonder if there are listservs or something where the top devs on the top distros could be asked why Firefox over Pale Moon, and so forth. Pale Moon seems closer to Linux's ideals.

Of course, really, when Linux desktops as a whole are only at 1% or so of the market, and have been stuck there for a long time, making too much of an effort to fight over how much of the 1% Pale Moon can be popular on isn't necessarily an efficient use of time and resources relative to battling for more Windows marketshare, or even developing a Mac version, or restarting Android development or whatever- unless it's just something that the people involved with the project want to do because they like Linux.

Just some thoughts. Probably ill-informed. Feel free to ignore them if they don't make sense. :) If you can find anything in there that's useful, though, I'm happy I was able to help a little bit.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Plans for Pale Moon for Linux 27

Unread post by Moonchild » 2016-09-24, 00:40

The issue is relatively simple. In general, operating systems have backwards compatibility, but not forwards compatibility.
So, in general, newer libs will support (sometimes to great extent) the APIs and calls that older version of the same libs had.

So, our building environment for generic binaries MUST be on the conservative/long-term-support side of Linux OSes.

Another point to keep in mind is that a binary release (as we make) is fully compiled. Whether your OS would prefer GCC 6.* or a newer runtime (glibc) library or not doesn't matter because of this backwards compatibility, unless you want to try building from source yourself (and may run into breaking source code issues there). The same reason why someone running Pale Moon on Windows doesn't need to have Visual Studio installed.

With the rebase, we are (as far as discussions with Travis have gone so far, and also mentioned in this thread's OP) planning to move to CentOS 7, to bump the "lowest common" version of required libs to what is generally in use on Linux desktops, and allowing the compilation to become more efficient (one can assume that added functionality in runtime libs is going to be an improvement... ;-) ).
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Plans for Pale Moon for Linux 27

Unread post by Walter Dnes » 2016-09-24, 02:12

Moonchild wrote:With the rebase, we are (as far as discussions with Travis have gone so far, and also mentioned in this thread's OP) planning to move to CentOS 7, to bump the "lowest common" version of required libs to what is generally in use on Linux desktops, and allowing the compilation to become more efficient (one can assume that added functionality in runtime libs is going to be an improvement... ;-) ).
Thanks for the info on the software side. Are you planning any changes on the hardware "lowest common denominator"? I understand that the current build expects SSE and SSE2 instructions on the CPU. That includes "pentium-m" (but not "pentium3m"), "pentium4", and "pentium4m" CPUs as the minimum. Has anyone ever requested an SSE-only contributed linux build? One reason I build my own copy of Pale Moon is to get all the optimization and speedup possible on my machines. It does help, i.e. "-march=native". I have to do separate builds for my 2 desktops, and my notebooks, but it's an automated process, so it only takes a few minutes of my personal time..
There's a right way
There's a wrong way
And then there's my way

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-09-24, 06:07

There will be little support for straight SSE instruction set builds in the rebase codebase going forward.. Why? Pale Moon's mission has never been one to support ancient hardware and software. Processors without at LEAST SSE2 are as old as Windows XP is. We are not in a position nor willing to support 15 year old computer technology in ANY way shape or form.

Truth be told, we should not be expected to support computer technology more than 10 years old. We are talking about a decade or older here.

Locked