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.Drugwash wrote: ↑2025-09-27, 21:15Nope 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".
Building Pale Moon on older hardware/Linux
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.
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.
-
UCyborg
- Astronaut

- Posts: 541
- Joined: 2019-01-10, 09:37
- Location: Slovenia
Re: Building Pale Moon on older hardware/Linux
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
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
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...
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.
-
UCyborg
- Astronaut

- Posts: 541
- Joined: 2019-01-10, 09:37
- Location: Slovenia
Re: Building Pale Moon on older hardware/Linux
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.
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.
-
andyprough
- Board Warrior

- Posts: 1183
- Joined: 2020-05-31, 04:33
Re: Building Pale Moon on older hardware/Linux
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.
-
Drugwash
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
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: 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.
-
UCyborg
- Astronaut

- Posts: 541
- Joined: 2019-01-10, 09:37
- Location: Slovenia
Re: Building Pale Moon on older hardware/Linux
Drugwash wrote: ↑2025-09-29, 07:55And 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.
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.
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.
-
Drugwash
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
Off-topic:
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.
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.
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!
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.
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.
-
andyprough
- Board Warrior

- Posts: 1183
- Joined: 2020-05-31, 04:33
Re: Building Pale Moon on older hardware/Linux
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.Drugwash wrote: ↑2025-09-29, 07:55As 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.
And a moderator might want to consider moving this thread into the How-To/Tutorial section.
-
Drugwash
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
It's but a feeble incomplete attempt at one. Thankfully the official development page provides as many details as possible.
That'd be unwise IMHO. There's too much off-topic here.andyprough wrote: ↑2025-09-29, 12:37And a moderator might want to consider moving this thread into the How-To/Tutorial section.
-
UCyborg
- Astronaut

- Posts: 541
- Joined: 2019-01-10, 09:37
- Location: Slovenia
Re: Building Pale Moon on older hardware/Linux
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.
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.
-
andyprough
- Board Warrior

- Posts: 1183
- Joined: 2020-05-31, 04:33
Re: Building Pale Moon on older hardware/Linux
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.
-
Drugwash
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
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.andyprough wrote: ↑2025-09-30, 17:44I'm thinking about converting my Ubuntu 18.08 virtual machine with the Pro subscription to use this gcc PPA you've found [...]
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:
Agreed. Hype, lies, a means to a nefarious end.
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...
-
andyprough
- Board Warrior

- Posts: 1183
- Joined: 2020-05-31, 04:33
Re: Building Pale Moon on older hardware/Linux
You are right, I meant 18.04. Bionic Beaver, what a name.Drugwash wrote: ↑2025-09-30, 18:20Could 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.andyprough wrote: ↑2025-09-30, 17:44I'm thinking about converting my Ubuntu 18.08 virtual machine with the Pro subscription to use this gcc PPA you've found [...]
-
UCyborg
- Astronaut

- Posts: 541
- Joined: 2019-01-10, 09:37
- Location: Slovenia
Re: Building Pale Moon on older hardware/Linux
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.
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.
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.
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.
-
Drugwash
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
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!
Off-topic:
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.
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.
-
Moonchild
- Pale Moon guru

- Posts: 38404
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Building Pale Moon on older hardware/Linux
Off-topic:
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.
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
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
Drugwash
- Lunatic

- Posts: 316
- Joined: 2016-01-28, 12:08
- Location: Ploieşti, Romania
Re: Building Pale Moon on older hardware/Linux
Off-topic:
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.
-
UCyborg
- Astronaut

- Posts: 541
- Joined: 2019-01-10, 09:37
- Location: Slovenia
Re: Building Pale Moon on older hardware/Linux
Off-topic:
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.
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.
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.
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.Moonchild wrote: ↑2025-10-01, 07:54I 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.
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.
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.
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.
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.Drugwash wrote: ↑2025-10-01, 06:49The 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).
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.
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.