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!
User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

Re: Plans for Pale Moon for Linux 27

Unread post by stevenpusser » 2016-09-24, 21:28

CharmCityCrab wrote:
...

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.
...
I'm that guy. The packages are built from the source by the openSUSE Build Service in various generic distro virtual machines. OBS also automatically sets up a repository for the finished product and publishes it--I just upload the three debianized source packages. I now label the original source tarball as a "repack", since I have to extract the .7z source archive, run that chmod command on it, and then recompress it to a tar archive that the Debian build tools will recognize, and finally rename that archive with the exact syntax that they will accept.

Anyone with a Debian-based distro and a reasonably modern machine can rebuild my sources natively--do these all as a normal user, no root or sudo)

1: Install packaging-dev
2: Download the PM orig.tar.xz and debian.tar.xz files from here
3: Extract both archives in a PATH that has no spaces in it (no "My Build" folders)
4: put the debian folder into the extracted source folder, and enter the source folder.
5: open a terminal in that folder, and run

Code: Select all

debuild -uc -us -jX
(replace the "X" with the number of processor cores you want to devote to the compiling)
6: If you are missing any build-dependencies, it will fail and tell you what you are missing. Install those, and repeat the build command.
8. I noticed that 26.4.1 builds mysteriously and randomly fail about 10% of the time about 10% of the way through--when the .build file gets to about 2 MB--on both my laptop and on the OBS. In that case, re-extract the sources and try again. The mozconfig file used by the build lives in the debian folder--just edit it if you want to make any changes.

(off tangent: I tried adding the Debian hardening build flags, which is a really good idea for something with a big attack surface exposed to the Net, but that caused an early build failure due to an undefined "main" symbol being added to an object file. The hardening flags don't allow that to proceed. That's something only the developers can fix...)

Possibly the PM source could include a debian folder derived from the one I use--some other projects provide them, as well as files meant for rpm package builds. (see SMPlayer source for an example) Those would only add a couple K to the source archive.

CharmCityCrab

Re: Plans for Pale Moon for Linux 27

Unread post by CharmCityCrab » 2016-09-25, 06:07

stevepusser wrote: I'm that guy. .
Thanks for doing that, by the way. :)

While I don't currently use Linux, I often have it in the back of my head as a failsafe should Windows take a direction that I really couldn't stomach.

People making sure my favorite software is available and as easy as possible for someone like me who isn't very technically adept to install and keep updated are part of what makes it a viable Plan B if one day I wake up and Windows has updated my PC automatically to something that won't let me view the file system, forces me to run everything as though my PC had turned into a thin client, integrates ads I can't turn off, and starts calling me Dave and singing Daisy (2001: A Space Oddessy movie reference). ;) The day may never come, but an operating system monopoly on a rolling release schedule with no ability userside to decline updates obviously has the theoretical capibility to take some turns that could prevent people from using their PCs the way they want to use them and which they find unacceptable with no real way to opt-out of.

I think the value of Linux goes beyond its actual userbase in that sense. Just knowing that I could hypothetically switch gives me peace of mind even if I never do it- and I'm sure I'm not the only one who feels that way. :)

Linux was hard for me to maintain in the past and screwed some things up, and I want to stay with Windows right now, but if one day Windows does something I can't tolerate, suddenly all that changes. I am sure there were a lot of people using Firefox as their web browser who thought that it was nice to have Pale Moon out there in case Mozilla took a turn they couldn't accept, but figured they'd always be Firefox users, and then one day Mozilla took the turn and they were Pale Moon users. :)

User avatar
mr tribute
Lunatic
Lunatic
Posts: 332
Joined: 2016-03-19, 23:24

Re: Plans for Pale Moon for Linux 27

Unread post by mr tribute » 2016-09-28, 22:28

I just want to thank the devs for making a great Linux version. The Linux installer works great. I am amazed by the speed of Pale Moon compared to Firefox. I am not only talking about rendering speed, but equally important UI speed.

Firefox is slowed down by Australis and GTK3. GTK2 is so much more responsive than GTK3. Please stay with GTK2 as long as possible. Scrolling is sometimes a mess in GTK3 apps.

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-09-28, 22:45

Allow me to reiterate. While we may eventually gain fully working GTK3 we see no reason to rip out support in the codebase for GTK2. In fact they share some common code so removing it would just be an artificial restriction on our part. Now, saying that.. There will likely come a time where GTK3 is the standard and everyone will be using it and our official builds may build with GTK3 but again you would still be able to build with GTK2 if you wished.

User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

Re: Plans for Pale Moon for Linux 27

Unread post by stevenpusser » 2016-09-29, 22:17

Apparently Firefox can also still be compiled against gtk 2. Debian's version of FF 49 is done that way.

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-09-29, 23:02

stevepusser wrote:Apparently Firefox can also still be compiled against gtk 2. Debian's version of FF 49 is done that way.
What Firefox does or doesn't do is irrelevant to Pale Moon. So, why would you bring this up.. This isn't a "Future of Firefox for Linux" thread and such a point would only lead to the continued misconception that somehow Pale Moon is not it's own totally independent and divergent thing.

doke2

Re: Plans for Pale Moon for Linux 27

Unread post by doke2 » 2016-10-14, 21:26

I suggest keeping 32 bit for now, but revisit the question in a year. As you point out, several major distros are dropping 32 bit. More importantly, a lot of the library developers are focusing more of their time on 64 bit, so the 32 bit code is starting to get tested less and less. That will make the 32 bit platforms slowly become less stable.

Pale Moon Nili

Re: Plans for Pale Moon for Linux 27

Unread post by Pale Moon Nili » 2016-10-15, 15:20

The announcement of dropping 32-bit is usually made by corporate distro or Canonical in person.
Debian will support i386 32-bit for atleast another decade.

Other distro like Slackware, Slitaz, LinuxBBQ, Alpine, Vsido, BunsenLabs, Puppy,ReactOS, Simplicity Linux and many more will support 32-bit for other 10+ years.
The other side BSD It will also continue using 32-bit.

I think it is very soon to drop support for 32-bit here on Pale Moon

Corportate Distro like Ubuntu, RHEL, CentOS etc.. have their reasons that I personally am not interested to follow. So please keep it running as much as possible.
If one day (in a later time) it will not be possible, I'll understand the Pale Moon decision.

Thank you for the support.
Nili

New Tobin Paradigm

Re: Plans for Pale Moon for Linux 27

Unread post by New Tobin Paradigm » 2016-10-15, 17:24

Thing is.. We are going to continue providing the 32bit generic version for a time.. Regardless of this, we have no intention of busting the ability to compile for 32bit.. That would be no real sense and would just be work to actually accomplish this..

We just wanted to reduce our release engineering for an architecture that doesn't seem to be sticking around for too much longer and merely purposed the idea to get an idea on who was actually still using 32bit linux distros. Obviously for the time being there is still a significant usage.. But this won't remain forever.. 32bit in linux is becoming less of a default or preferred choice.. This is a fact and with limited resources we have to focus on what most users are using.. And most users of our generic build are 64bit users. But as stated, there is still a good chunk also using 32bit so we will revisit it at a later date.

In general, you guys have to understand that what is possible on a practical or technical level may not be desirable or reasonably feasible. On a technical level we COULD restore and produce OS/2 builds.. It was possible before and it is still TECHNICALLY possible now.. But that isn't practical or at this point reasonably feasible. Or perhaps a slightly relevant example.. There should be little reason why you couldn't compile Pale Moon for PowerPC Linux.. There might still be some PPC bits in the build system and there is obviously Linux support.. But this isn't desirable.. OR realistically feasible.. It wouldn't be easy to accomplish at the current state of the codebase but it could be done on a technical level and may even be practical.. It was before and could be again.. But there isn't much call for PPC Linux so in a cost/benefit type of evaluation.. This isn't something we are gonna do..

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-10-15, 17:53

32-bit linux uses 32-bit time. The valid date range is 2^31 seconds before 0000hr Jan 1, 1970 until (2^31 - 1) seconds after 0000hr Jan 1, 1970. This is also known as the "Y2K38 problem". Here's an example I just ran in a 32-bit QEMU VM.

Code: Select all

[g32gst1][root][~] date --date='@-2147483649'
date: invalid date '@-2147483649'

[g32gst1][root][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901

[g32gst1][root][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038

[g32gst1][root][~] date --date='@2147483648'
date: invalid date '@2147483648'
64-bit linux (and 64-bit posix-type OS's in general) use 64-bit time, which covers +/- the heat death of the universe. Apparently, linux time_t is currently dependant on the size of the structure, and making the appropriate kernel change will massively break userland ABI/API. This means every non-trivial 32-bit linux program would require at least some changes.
There's a right way
There's a wrong way
And then there's my way

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

Re: Plans for Pale Moon for Linux 27

Unread post by Moonchild » 2016-10-15, 19:11

Walter Dnes wrote:32-bit linux uses 32-bit time.
Not exactly relevant to our uses, is it? :)

(And come 2038, I'm sure the computing landscape has considerably altered...)
Off-topic:
I never understood the necessity to count milliseconds since epoch in Linux. It's an arbitrary counter, and people should be able to easily enough change its arbitrary nature if it becomes a problem.
"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

Weasel
Apollo supporter
Apollo supporter
Posts: 35
Joined: 2016-10-10, 15:59

Re: Plans for Pale Moon for Linux 27

Unread post by Weasel » 2016-10-16, 10:13

Well honestly I can understand if some OSes go 64-bit only but application are a somewhat different matter imo. Of course everyone knows Windows can run 32-bit apps on 64-bit, but on Linux there's multilib so 32-bit still works on 64-bit OS (in some cases preferable), but not the other way around. Wine in particular can still run 16-bit apps in 64-bit OS without emulating the instructions! (as long as they are Windows apps, not real mode DOS). Obviously if it will come to a point where no 32-bit libs are available (even on 64-bit OS) enough to run 32-bit apps, it will be a disaster, tbh don't wanna imagine it. It's not necessarily for new apps but the old ones.

And honestly 99% of apps don't even need 64-bit, unlike the 16-bit>32-bit transition, since they use well under 3GB of RAM.

Dustie_Rose
Apollo supporter
Apollo supporter
Posts: 44
Joined: 2016-11-14, 15:34
Location: Texas U.S.

Re: Plans for Pale Moon for Linux 27

Unread post by Dustie_Rose » 2017-03-19, 09:37

Hello Palemoon Linux peeps;

I am catching up in this forumn on reading catchup. Just wanted to say I have participitated in the survey and read the results. I was not surprised to see a 30% user margin for Linux Palemoon. In response to the issue of continuation of 32 builds, I have read the same from most forumns or updates of the mainstream distro versions across the board.
My two cents, I have several 5+ yr. old laptops and one 32bt. Windows XP still operational. I reprogrammed my 32 DELL Inspiron 1535 (9 yrs old), to Linux Mint 17.3, which was made 32 @ 64 versions, and this diehard laptop works like a new one and much faster than alot of newer versions in 64. Some distro versions work better on older hardware. I am not experienced enough to do code builds yet but I realize how much extra work it takes.
Dustie Rose :coffee:

Locked