Building Pale Moon on older hardware/Linux

General project discussion.
Use this as a last resort if your topic does not fit in any of the other boards but it still on-topic.
Forum rules
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.

Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
User avatar
UCyborg
Astronaut
Astronaut
Posts: 541
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: Building Pale Moon on older hardware/Linux

Post by UCyborg » 2025-09-28, 11:06

Hm, OK, TBH I'm not sure where the idea that websites should retain basic functionality when viewed by more primitive browser came from. Some sites don't display at all without JavaScript.
Drugwash wrote:
2025-09-27, 21:15
Nope you're not. There was a time, long ago, when I could hardly wait for new versions of software to come out, because they were really improving, fixing bugs etc but were still compatible. Now I dread hearing that new versions came up, thinking "what the heck did they take out now, what new bugs and/or government backdoors have been slipped in?" But more often than not I see "minimum requirement [...] - not compatible with <my OS> anymore".
I've seen one case on Android where the changelog just said minor improvements while at the same minimal required Android version was bumped up.

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-09-28, 11:22

UCyborg wrote:
2025-09-28, 11:06
Some sites don't display at all without JavaScript.
And in an honest, common-sense world they would not be visited anymore, ever. But we're not living in such a world, are we. And whose fault is it, may I ask...
UCyborg wrote:
2025-09-28, 11:06
I've seen one case on Android where the changelog just said minor improvements while at the same minimal required Android version was bumped up.
Well isn't that just a minor improvement for so many "skilled programmers"...

It's all about money, and I dare anyone to prove me otherwise.

User avatar
UCyborg
Astronaut
Astronaut
Posts: 541
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: Building Pale Moon on older hardware/Linux

Post by UCyborg » 2025-09-28, 18:49

It's always about the money.

The way desktop got pushed out in favor of mobile, it seems to me you're slightly more at disadvantage these days with out-of-date smartphone than with out-of-date computer.

And with the way sites and their services are, you'd be excluded or disadvantaged in some way or at least inconvenienced if you tried to avoid them. Then you're on your own again because there are rarely, if ever, any allies by your side.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1183
Joined: 2020-05-31, 04:33

Re: Building Pale Moon on older hardware/Linux

Post by andyprough » 2025-09-29, 03:58

Drugwash wrote:
2025-09-28, 11:22
UCyborg wrote:
2025-09-28, 11:06
Some sites don't display at all without JavaScript.
And in an honest, common-sense world they would not be visited anymore, ever. But we're not living in such a world, are we. And whose fault is it, may I ask...
What's been very strange to me for awhile is how we live in a world where the knowledgeable, technical type of people mostly call for efforts to reduce energy usage in order to reduce environmental effects. But at the same time we can't have a webpage with a cooking recipe without at least 100mb of js, images, videos, advertisements being loaded. Can't just have the text of the recipe in a few kb's, maybe on a pleasant looking background. No, it has to be an endless scrolling site, with comments by disqus with likes and dislikes and emojis and animated gifs and autoplay media. With AI generating fake content and fake interactions by fake followers in order to generate the appearance of popularity. And all content has to be duplicated on ten different social media platforms, each with all their fake comments by fake followers, likes, dislikes, emojis, gifs, advertisements, etc. So now that one single recipe for a ham casserole has grown from a few bytes of text to over 1GB of useless nonsense.

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-09-29, 07:55

andyprough wrote:
2025-09-29, 03:58
What's been very strange to me for awhile is [...]
What's to wonder when nowadays the OS itself serves advertising, "suggestions", offers to "help" through a hallucinating entity and so on...
Well, they needed a justification for the ever increased hardware capabilities due to technological advancements so they had to give computers and devices heavier tasks to perform. Then, much heavier tasks devised by software engineers required more capable hardware. And so on on an endless cycle.
And, of course, everything costs money. But people at some point realized they could host content at home on their own computer, much cheaper, without bells and whistles. That would've hurt the business, so public hosts appeared, and static IPs dissapeared. Hosts either cost money or are loaded with advertising, because - well - they need to pay for existing too. We can't have simple content hosted at home anymore, and we either pay for ad-free subscriptions or choke on ads until we die. Machines choke on ads (and useless/fake content, as you said), they "grow old" faster, their lifetime is limited by design - ours too, of course - and the world economy is happy. We're not, but who cares. Of course, all this is an oversimplification.

Will it ever end? Not until there's only one human left on Earth - they won't have who to sell anything to anymore. Maybe to the aliens? A huge intergalactic post sign saying «Come to Earth, life here is cheap». Of course that'd be a lie but, who knows, maybe they'd fall for it...

And that's how we got [almost] completely off-topic. Because everything in life is related even when we don't realise it.
We've got a viral infection, and we stubbornly try to treat it by taking aspirin for the fever. It won't go away - we need antibiotics.

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

As for the topic title... well, I may not be at all the best person to post a tutorial on that. These last years I kept installing and upgrading whatever I felt necessary for the task at hand. Sometimes from unofficial sources, sometimes built by myself from available sources. Never kept track of anything. Chaotic, I know. Anyway, for what it's worth here's what I did on my Linux Mint 19.2 Cinnamon (based on Ubuntu 18.04) running on a 2009-model Samsung NP-R580 slightly upgraded (Intel i5 M460 CPU, 8GB DDR3 RAM, NVIDIA GT218M [GeForce 310M] 512MB VRAM).

The last major change was installing GCC9 from the Ubuntu Toolchain PPA mentioned somewhere above. Instructions to add the PPA are found on that page. It was an additional install alongside the default GCC 7.5, not set as default, as other applications that I might wanna update from sources in the future may not like newer tools or I may not be able to change their configurations in order to detect those tools.

Therefore the .mozconfig file had to be slightly changed in order to detect the newly installed GCC by its real name instead of the default version.
Another personal option was the addition of mk_add_options MOZ_MAKE_FLAGS="-j2". That was needed because my machine's CPU is an old dual core with hyperthreading, and not using that limitation at first build attempt used up all the 8GB of RAM and went into swap too.
Actual file is attached here:
mozconfig_SSE2.zip
Can't remember if I had to install any additional development tools/libraries at the time. Dependencies and hardware requirements are mentioned here anyway, and the build script would notify if anything is missing or incompatible. The instructions there are pretty comprehensible and straightforward.

Now, for first build that's all that has to be done. For updating the code from repository when a new version is out I use the following commands in Terminal:
git reset --hard -q
git pull origin release
Don't know if it's the best practice but that's the best way to avoid issues if the local code has somehow been tampered with (hardware failure, accidental file deletions/editing etc). Don't do that if you intentionally modified any project files - all your changes will be removed without warning!
Unfortunately I could never understand Git and its operation so can't say how to update the code from repository while keeping your own changes. That's my own limitation.

And that's about it. Yet another aspirin against the rabid bite of Life.
You do not have the required permissions to view the files attached to this post.

User avatar
UCyborg
Astronaut
Astronaut
Posts: 541
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: Building Pale Moon on older hardware/Linux

Post by UCyborg » 2025-09-29, 09:22

Drugwash wrote:
2025-09-29, 07:55
And that's how we got [almost] completely off-topic. Because everything in life is related even when we don't realise it.
Unfortunately I could never understand Git and its operation so can't say how to update the code from repository while keeping your own changes. That's my own limitation.

And that's about it. Yet another aspirin against the rabid bite of Life.
Off-topic:
That's natural and keeps conversation interesting. I'm not against topics steering into other direction, even though it may be annoying when you try to find some important piece of technical information in the old topic in the future. Forums don't naturally the best to that kind of flow.

I'd add to andyprough's observations that necessitating hardware upgrades to keep up with increasingly complex software doesn't strike me as green approach. I also find people to be incredibly impatient in general.
Drugwash wrote:
2025-09-29, 07:55
Unfortunately I could never understand Git and its operation so can't say how to update the code from repository while keeping your own changes. That's my own limitation.
One way may be using a branch. So when you have a clean state, make a branch, do whatever changes you want and commit your changes, go back to the main branch, pull new changes, then rebase your branch on top of the main branch.

I'm not the expert either and probably often resort to less than optimal approaches when it comes to computers in general. So doing it the Flintstones way.

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-09-29, 10:48

Off-topic:
UCyborg wrote:
2025-09-29, 09:22
That's natural and keeps conversation interesting.
I know and it's perfectly alright with me but generally forum boards have a relativly strict on-topic policy - some more than others. Wouldn't want to inadvertently step on moderators/admins' shoes with all this life-encompassing discussion even when it's located in the General section.
UCyborg wrote:
2025-09-29, 09:22
I'd add to andyprough's observations that necessitating hardware upgrades to keep up with increasingly complex software doesn't strike me as green approach. I also find people to be incredibly impatient in general.
Even if I don't buy into this "green" hype - or at least not entirely - it still is a huge waste to chuck away hardware that's only a few years old just because someone pushed some new gimmick into a chip that makes existing software incompatible, or some new software decided it should require much more resources than current hardware is capable of. All in the name of "security" and "progress". Bah! :thumbdown:
And dunno what current situation is globally regarding recyling of electronics, but after watching Cosima Dannoritzer's 2010 documentary Prêt-à-jeter (The light bulb conspiracy 1) years ago I realized humanity is simply irresponsible. And greedy. At least at the top.

As for people... Generally young people tend to be impatient, and require the newest/shiniest/most powerful/etc whatever gimmick the advertising networks are throwing in their face. Wouldn't blame them - we (or at least I) were kinda the same at their age. Although times were a bit different back then. But today it's not about our own choices based on desires, needs, and possibilities - we are being driven, forced even, to constantly "upgrade" whether we want/need it or not. So even if young people wanted to hold onto their current devices and objects, they couldn't.
UCyborg wrote:
2025-09-29, 09:22
One way may be using a branch. [...]
Well, that's one of the many things that I can't seem to wrap my head around. And when I couldn't get it from the very beginning there's slim to none chances of getting it later on. Wouldn't be the first thing I can't cope with, and definitely not the last considering my memory is also failing quite rapidly (most likely some genetic disorder inherited from my mother who passed last year with severe dementia).

Thing is, the short Z80 part aside most of my life I've used some version of MS Windows - that is, a full GUI operating system. Never fancied command line. That's also one of the reasons why I took on Linux so late in life - none of the [available and free] distros were ready for full GUI operation when I tested them in the past. To be honest, they still aren't, completely, but are much more usable on a daily basis today than back then. Still, applications like git that work in command line only will never get under my skin. I know there may be a few GUI front-end attempts at driving git - I do have Giggle for one and it's so limited, and also git gui which I can't make heads or tails of - but the logic of the git system itself eludes me for the most part. So I'll have to stick with the very basics of git: clone a repository, and update the code when needed (or when I remember about it).

1 Try to find the full 1h14m version not the shorter 56m one, if interested. Found this one with Spanish audio, others I had found previously are not available anymore (accounts deleted etc). EDIT: Found one in English here.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1183
Joined: 2020-05-31, 04:33

Re: Building Pale Moon on older hardware/Linux

Post by andyprough » 2025-09-29, 12:37

Drugwash wrote:
2025-09-29, 07:55
As for the topic title... well, I may not be at all the best person to post a tutorial on that. These last years I kept installing and upgrading whatever I felt necessary for the task at hand. Sometimes from unofficial sources, sometimes built by myself from available sources. Never kept track of anything. Chaotic, I know. Anyway, for what it's worth here's what I did on my Linux Mint 19.2 Cinnamon (based on Ubuntu 18.04) running on a 2009-model Samsung NP-R580 slightly upgraded (Intel i5 M460 CPU, 8GB DDR3 RAM, NVIDIA GT218M [GeForce 310M] 512MB VRAM).

The last major change was installing GCC9 from the Ubuntu Toolchain PPA mentioned somewhere above. Instructions to add the PPA are found on that page. It was an additional install alongside the default GCC 7.5, not set as default, as other applications that I might wanna update from sources in the future may not like newer tools or I may not be able to change their configurations in order to detect those tools.

Therefore the .mozconfig file had to be slightly changed in order to detect the newly installed GCC by its real name instead of the default version.
Another personal option was the addition of mk_add_options MOZ_MAKE_FLAGS="-j2". That was needed because my machine's CPU is an old dual core with hyperthreading, and not using that limitation at first build attempt used up all the 8GB of RAM and went into swap too.
Actual file is attached here:
mozconfig_SSE2.zip

Can't remember if I had to install any additional development tools/libraries at the time. Dependencies and hardware requirements are mentioned here anyway, and the build script would notify if anything is missing or incompatible. The instructions there are pretty comprehensible and straightforward.

Now, for first build that's all that has to be done. For updating the code from repository when a new version is out I use the following commands in Terminal:
git reset --hard -q
git pull origin release
Don't know if it's the best practice but that's the best way to avoid issues if the local code has somehow been tampered with (hardware failure, accidental file deletions/editing etc). Don't do that if you intentionally modified any project files - all your changes will be removed without warning!
Unfortunately I could never understand Git and its operation so can't say how to update the code from repository while keeping your own changes. That's my own limitation.

And that's about it. Yet another aspirin against the rabid bite of Life.
Nice, we have our tutorial now! Maybe you could mark this thread as "Solved" to make it easier for people to find it in the future.

And a moderator might want to consider moving this thread into the How-To/Tutorial section.

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-09-29, 13:08

andyprough wrote:
2025-09-29, 12:37
Nice, we have our tutorial now!
It's but a feeble incomplete attempt at one. Thankfully the official development page provides as many details as possible.
andyprough wrote:
2025-09-29, 12:37
And a moderator might want to consider moving this thread into the How-To/Tutorial section.
That'd be unwise IMHO. There's too much off-topic here. :)

User avatar
UCyborg
Astronaut
Astronaut
Posts: 541
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: Building Pale Moon on older hardware/Linux

Post by UCyborg » 2025-09-29, 23:20

Off-topic:
Didn't know about that specific documentary, though I've read about Centennial Light before. At my home, a freezer cabinet that would be over 40 years old this year was still in use for the first half of 2022 or so. But the sealing material covering certain components deteriorated to the point that cooling performance started to suffer, the freezer was replaced that year. The people that might remember its exact age are long dead.

I don't like obsession with security and what they call "progress" these days.

I'm still mostly Windows guy. I started with command line when using Git for the first time, that must have been about a decade ago, when I took it upon myself I want to get one of the open source variations of Quake II engines running on Linux natively, one of the forks that remained Windows only. It kinda worked, but it didn't handle case sensitive file system well and it still saved config/saves to installation folder. I ended up modifying some data files to fix case where needed, I suspected something should have been done on the engine side as well, though I didn't look further into it. I tried to do as much on my own by just studying how to use SDL2 library, I only peeked at another similar engine for how to get audio playing through SDL2.

I wouldn't have anything to show if graphics wasn't done with OpenGL as-is, which is already cross-platform. Comprehending rendering code is about as hopeless as learning Chinese, I'm too dumb for that.

Anyway, Git was used to log subsequent changes to the code after I got the game running on Linux for the first time. I wasn't focused on Git as much, basics didn't seem too scary. At the same time, I got familiar with tagging and publishing to GitHub, at the basic level at least. Back then, my bigger question was, what do I use instead of Visual Studio on Linux.

I usually interact with Git using TortoiseGit (it comes with help file with pictures), which integrates its commands in Explorer's context menus on Windows. I don't know if there were any graphical frontends back then on Linux, I didn't know about any you mentioned, but I know Visual Studio Code can interact with Git.

I don't know what to say about the genetic disorder. Words wouldn't be too helpful in any case. It's already pretty bad out there without our own bodies failing us.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1183
Joined: 2020-05-31, 04:33

Re: Building Pale Moon on older hardware/Linux

Post by andyprough » 2025-09-30, 17:44

Drugwash wrote:
2025-09-29, 13:08
andyprough wrote:
2025-09-29, 12:37
Nice, we have our tutorial now!
It's but a feeble incomplete attempt at one. Thankfully the official development page provides as many details as possible.
I'm thinking about converting my Ubuntu 18.08 virtual machine with the Pro subscription to use this gcc PPA you've found and your .mozconfig and making tarball binaries of Pale Moon available for those older machines and older distros that could use it. I could do it on a fairly regular basis. Might take me a day or two after the official releases are out, but my machine can build Pale Moon in just 15-20 minutes, so not much of a strain for me. I should have some time tomorrow to set up the build environment and run a test build.

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-09-30, 18:20

andyprough wrote:
2025-09-30, 17:44
I'm thinking about converting my Ubuntu 18.08 virtual machine with the Pro subscription to use this gcc PPA you've found [...]
Could be an idea for the less fortunate. Just make sure 18.08 doesn't have higher library versions that 18.04, otherwise the userbase could be very limited.

It would be quite useful if coltson in the original topic would reveal their hardware and OS details, maybe an even earlier OS version would be required.
Personally I'm fine with building my own once in a few months as long as requirements don't change. If anything it keeps me on my toes. :)
Off-topic:
UCyborg wrote:
2025-09-29, 23:20
I don't like obsession with security and what they call "progress" these days.
Agreed. Hype, lies, a means to a nefarious end.
UCyborg wrote:
2025-09-29, 23:20
I usually interact with Git using TortoiseGit
Back in the day it used to be a TortoiseSvn; long dead I presume. I used to use VC6 for a short while, did its job. Nothing as fancy as porting a serious game though. Nowadays I mostly dabble in Python3, some javascript in Cinnamon Spices... Forgot a lot of AutoHotkey 1.x which used to be my language of choice for a few good years; sort of the Windows equivalent of Python - that is, an interpreted language. We all do whatever we [still] can, I suppose...

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1183
Joined: 2020-05-31, 04:33

Re: Building Pale Moon on older hardware/Linux

Post by andyprough » 2025-09-30, 20:18

Drugwash wrote:
2025-09-30, 18:20
andyprough wrote:
2025-09-30, 17:44
I'm thinking about converting my Ubuntu 18.08 virtual machine with the Pro subscription to use this gcc PPA you've found [...]
Could be an idea for the less fortunate. Just make sure 18.08 doesn't have higher library versions that 18.04, otherwise the userbase could be very limited.
You are right, I meant 18.04. Bionic Beaver, what a name.

User avatar
UCyborg
Astronaut
Astronaut
Posts: 541
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: Building Pale Moon on older hardware/Linux

Post by UCyborg » 2025-09-30, 20:19

Off-topic:
Subversion (SVN) and TortoiseSVN are actually still alive and well. My workplace still uses SVN.

That Quake II engine I messed with is called Berserker@Quake2. Old school engines by id Software tend to be fairly platform agnostic as it is, one of their employees back in the day did official Linux ports. Berseker is the odd one as the author put most code in one huge source file and there's one big header file. :D

I did some patches for the handful of other old closed-source games, a mix of editing of binaries with OllyDbg while some code for certain games was put in a proxy DLL mostly written in C, with few bits of x86 assembly there and there. I did actually use VC6 to compile the latter. I found linking to C runtime DLL more elegant than static linking, plus msvcrt.dll is available almost everywhere out-of-box.

I haven't got familiar with any flavor of Python, though encountered it a number of times as a dependency. I managed to build LineageOS 14 for my old phone at some point, turned out it all starts with a Python script that clones many Git repositories of components that make up the system. My computer is way out of the league to build any recent Android it seems.

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-10-01, 06:49

andyprough wrote:
2025-09-30, 20:18
You are right, I meant 18.04. Bionic Beaver, what a name.
Ah, I thought they had released a lesser known minor version. It's OK then. :)
As for the names... Never understood this obsession with alphabet order, strict codenames - animals in Ubuntu, women in Mint and so on - when numbers are shorter and more clear. I know my Mint is 19.2 but no idea about de codename; should be a woman name which must end in A. Go figure! :crazy:
Off-topic:
UCyborg wrote:
2025-09-30, 20:19
Subversion (SVN) and TortoiseSVN are actually still alive and well.
That's a surprise. Maybe some name got mixed in my head, I knew for sure there was a system that got superseded and perished. Maybe CVS...? My memory is too hazy.

I think I saw one of the Quake games mentioned at Rob Savoury's PPA. Wasn't much of a fan even back in the day, and now I'm too old, my eyesight got too bad to play such games. Or any games, actually.

The x86 code "scared" me. The instruction set was way too large compared to the Z80 set. That and the need for additional tools - decompiler, compiler, linker - made me avoid working with x86. There was an exception though when I worked on slightly enhancing a Windows 9x logo loader that would mimic the XP loader. It was 16bit code, and complemented it with an AHK script that would modify bitmap files by adding animation data within unused bytes. It's in my sig, first link (the large bundle, WLL subfolder).

I got close to Python for being somehow familiar, similar to AHK in that it can be run instantly without compilation. When building something from scratch or even modifying someone else's code it's much more handy to have it run immediately for testing rather than waiting for compilation and linking. The downside is that it's less efficient speed-wise than compiled code.
In Mint (and other Linux flavors I presume) Python is used for building various system tools and helper scripts, which can easily be fixed/modified/enhanced. I did modify some of those tools for my own usage, and also built a few "toys" that would help my daily usage. That, together with a few modded Cinnamon Spices (applets, extensions) make life a little bit better. :)

Personally I wouldn't even bother building an Android system. What I would need though would be a good simple Android emulator, or loader (like a virtual machine). Recently I bit the bullet and installed a couple apps on a spare Samsung phone that I don't use. One of them is suspectly slow and faulty when it comes to downloading small (1-2MB at most) footages from a Wi-Fi camera. My suspicion is that my [private] footages are unconditionally uploaded to some chinese servers (cloud?) even when I didn't agree to any such option and there would be no reason to upload them when all I wanna do is downloading them from the camera's microSD card to the phone, locally. If I disconnect the router from the web everything fails. I'd like to look into those apps and test them on the notebook since they take quite a lot of resources on the phone (draining battery like hell even when it's hooked to the charger). I looked for some Android emulator/loader but didn't find any that would fit my needs.

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

Re: Building Pale Moon on older hardware/Linux

Post by Moonchild » 2025-10-01, 07:54

Off-topic:
Drugwash wrote:
2025-10-01, 06:49
Maybe some name got mixed in my head, I knew for sure there was a system that got superseded and perished. Maybe CVS...? My memory is too hazy.
I also thought SVN was pretty much unused these days as it is extremely rudimentary in comparison to later systems, and very resource/time intensive to use.
By the way: "CVS" is just the generic term "Concurrent Versioning System" which is the type of system SVN, mercurial, git, etc. are; it's not any single one in particular.
"There is no point in arguing with an idiot, because then you're both idiots." - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Drugwash
Lunatic
Lunatic
Posts: 316
Joined: 2016-01-28, 12:08
Location: Ploieşti, Romania

Re: Building Pale Moon on older hardware/Linux

Post by Drugwash » 2025-10-01, 08:24

Off-topic:
Moonchild wrote:
2025-10-01, 07:54
By the way: "CVS" is just the generic term "Concurrent Versioning System" which is the type of system SVN, mercurial, git, etc. are; it's not any single one in particular.
Yes, it's a generic term, I vaguely remember that. But still there was at least a tool that comprised that acronym or a similar one in its name, and that particular versioning system - which I believe preceded SVN - had been superseded by SVN and dissapeared, or maybe it just morphed into SVN. I know I had a different versioning tool before Tortoise, one that used the old system, then I installed TortoiseCVS, and I'm not sure if I ever switched to TortoiseSVN after that, as at the time I was running Windows 98SE and maybe SVN was too new and incompatible. This bad memory doesn't help much. :(

User avatar
UCyborg
Astronaut
Astronaut
Posts: 541
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: Building Pale Moon on older hardware/Linux

Post by UCyborg » 2025-10-01, 19:30

Off-topic:
Moonchild wrote:
2025-10-01, 07:54
I also thought SVN was pretty much unused these days as it is extremely rudimentary in comparison to later systems, and very resource/time intensive to use.
By the way: "CVS" is just the generic term "Concurrent Versioning System" which is the type of system SVN, mercurial, git, etc. are; it's not any single one in particular.
CVS was an actual revision control program as well, see https://en.wikipedia.org/wiki/Concurrent_Versions_System. You might also find this video amusing, where Linus Torvalds presents his then new Git. And has some special remarks for CVS, Subversion and their users. I wouldn't take them personally, but I wonder if that's the reason for video being de-listed. I found the link in TortoiseGit's help file.

I think Subversion is just one of the signs of my workplace being stuck in the 90s. Who else doesn't have purchases of hardware / software and its upgrades handled online? What serious company uses the Community edition of Visual Studio for developing proprietary paid-for software?

I don't want to rant too much about the company here, but I got the honor of getting access to the repo some time back, while programming is not my role there, they figured it's a good idea since I'm not totally clueless and I can fix some issues myself rather than waiting years before anyone else picks them up. Still, it's not something to do every day, for the sake of sanity.

I managed to replicate the entire Subversion repo in Git (you can use the latter as SVN client), took a couple of tries, to get those branches / tags right. Not necessary if you're good with trunk alone, but I was curious and just wanted to get accurate history. Git made a bunch of extra branches I don't really need since they "branch" / "tag" subfolder of the trunk. Still, not too bad, all things considered. It's nice to be able to prepare / edit commits locally before pushing to repo. Even so, it still happens so easily that you push some stupidity to the repo that you didn't want to.

Bureaucratic part of merges doesn't work the way it's expected with SVN. Playing with the test repo, git svn can't update svn:mergeinfo property properly (it stores merged revision numbers and where they come from) when the hierarchy of the branch diverges from normal. TortoiseSVN would also generate commit message indicating both revision numbers being merged and combine messages from revisions in question, TortoiseGit operates differently in that regard.
Drugwash wrote:
2025-10-01, 06:49
That's a surprise. Maybe some name got mixed in my head, I knew for sure there was a system that got superseded and perished. Maybe CVS...? My memory is too hazy.
SVN / Subversion is still maintained. But not used at many places anymore. I was surprised that VisualSVN Server for Windows, that its web interface in the latest version doesn't work with Pale Moon out-of-box.
Drugwash wrote:
2025-10-01, 06:49
I think I saw one of the Quake games mentioned at Rob Savoury's PPA. Wasn't much of a fan even back in the day, and now I'm too old, my eyesight got too bad to play such games. Or any games, actually.
I actually never got deeply into early Dooms / Quakes either. Though I finished Quake IV. With Dooms, maybe I finished 4/5 of first episode of Doom I many years ago at most. I got farthest in Doom III (but not to the end), but one is much different from the first two and there was the time I was really into horror genre.
Drugwash wrote:
2025-10-01, 06:49
The x86 code "scared" me. The instruction set was way too large compared to the Z80 set. That and the need for additional tools - decompiler, compiler, linker - made me avoid working with x86. There was an exception though when I worked on slightly enhancing a Windows 9x logo loader that would mimic the XP loader. It was 16bit code, and complemented it with an AHK script that would modify bitmap files by adding animation data within unused bytes. It's in my sig, first link (the large bundle, WLL subfolder).
I got the impression only handful matter in practice. Bunch of moving values around and doing math operations / bit manipulation on them. Why anything interesting happens after that is anyone's guess.

Interesting, there was a time when you read about changing Windows boot screen more often. One thing I'm still curious about, how come Windows 2000 was the only version (that I know about) with the actual progress bar during booting. With transition to flash storage, even Win10 is quick past boot screen, so that would be another reason for boot screen modding to go out of fashion.
Drugwash wrote:
2025-10-01, 06:49
Personally I wouldn't even bother building an Android system.
I was happy to see the phone boot with it. It also has a personal touch, my own digital signature. But corporations don't want us to personalize.

I'm very out of the loop when it comes to Android emulators. I find even desktop Linux to be finnicky on virtual machines (going by experiences with VMware and VirtualBox).

For Windows and MacOS, there's BlueStacks. On Linux, I'd probably try WayDroid first. I suspect BlueStacks uses modified VirtualBox under the hood. At least when I checked it few years back, it was either logs or some other aspect suggesting VirtualBox. Somehow they seem to be able handle graphics better than typical virtualizer.