Note by Apollia on Nov. 8, 2023: Please join my Patreon if you'd like to support me and my work!

My main personal website is now I'm still not sure what to do with Astroblahhh.Com, so it's mostly staying as-is for now.

Blog Main Archive - Jul 2017

Posts Below
7/1/2017 - Legacy code woes (Programming)
7/31/2017 - How to make YouTube HTML5 audio work with Lighthouse 64 Puppy Linux 6.02 Beta 2 and a Sewell USB Sound Box (Puppy Linux)
7/31/2017 - How to compile Pale Moon 27.4.1 from source code in Lighthouse 64 Puppy Linux 6.02 Beta 2 (Puppy Linux)
7/31/2017 - CATcerto (Music)


   ▲ Top  ▼ Bottom  △ TOC   ↓ Down
Legacy code woes
Saturday, July 1st, 2017
23:42:28 GMT


I've been feeling so overwhelmed lately by my Puppy Linux Setup Kit, my messy neglected websites, and Astroblahhh Desktop. Overwhelmed and stuck.

Actually, I've felt that way for years, which is probably part of why I've procrastinated so much about continuing to work on these projects at all.

But, recently, reading some articles about working on legacy code made me feel better and less worried that maybe I'm just not really cut out to be a programmer.

I hadn't realized that even much better, wiser, more experienced programmers than me can have immense trouble with this kind of project if they make the kinds of mistakes I've been making, such as trying to change too many things at once, not doing test-driven development (TDD), and overly optimistically attempting "big-bang rewrites".

Here are a couple of those articles:

The Legacy Code Lifecycle
April 25, 2012 from

How to Improve a Legacy Codebase
May 30, 2017 from

Those articles and their advice look very wise to me, not that I would know. But I'm guessing that doing even just some of what is suggested might go far better for me than doing what I've been doing.

Even though (as far as I know) I'm the only person who ever worked on my Puppy Linux Setup Kit, Astroblahhh Desktop, and other languishing projects of mine, these projects have all been through the entire lifecycle mentioned in that first article, and have long been stuck in the last phase.

In many ways, I unintentionally designed things naively and poorly at the outset. I didn't document things well enough, and I took such long breaks from working on my own code that by the time I returned to it, I had forgotten a ton of details.

And for many years, I didn't even know what test-driven development (TDD) was. I finally tried it in 2015 or 2016 and liked it, but, quite unwisely, I still usually haven't gone to the trouble lately, and I probably ought to learn more about it so I can be more sure I'm doing it right.

I'm quite frustrated that I haven't gotten much more done by now, but, I probably shouldn't be too hard on myself. If I were really a hopelessly bad programmer:

So, I'm definitely not even close to totally giving up on programming forever (though I feel very intimidated by the idea of trying to make a serious career out of it). But I think I need to be a lot more cautious and less naively optimistic than I was in the past.

The idea of releasing more of my work more frequently definitely appeals to me a lot. I've felt so guilty about not creating and/or releasing way more useful (or otherwise beneficial) stuff into the world already. And many people think sharing in-progress work publicly and frequently can result in much better software.

Preparing things for publication definitely encourages me to do a better job than I tend to do with things I don't expect to release anytime soon (if ever). Not that I don't still make numerous dumb mistakes either way, but I think maybe I make fewer dumb mistakes when I create something with publication in mind.

I sure wish I could do a perfect job on everything all the time, but, I've learned that I better not insist too stubbornly on perfection or I'll never get anything done.

Fortunately, already, without even knowing it (at first), I seem to have been moving away from the "cathedral" model of free/libre software development, "in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers", toward the "bazaar" model, "in which the code is developed over the Internet in view of the public".

That happened because I finally learned more about how to use Git and GitHub, so I've been sharing my work more frequently by releasing it on GitHub. Currently, that's much easier than uploading files to my own websites.

So, currently, this is the place to look for my absolute newest updates to whatever software projects:

Not much of what I've been adding lately has seemed notable enough (or easy to install or interesting or useful enough) for me to announce in new blog posts, so, I mostly haven't mentioned them here.

In retrospect, I maybe shouldn't have even announced Salty XML Transformer, because it's such a chore even for me to install, because I haven't made even my own not-yet-released Puppy Linux Setup Kit fully up to date yet.

By the way, I recently found out that ever since sometime in July 2016, the latest released version of the Puppy Linux Setup Kit (v1.1) was far less functional than I thought, because unfortunately, some of the files the old setup kit optionally tries to download are no longer available. Many went missing simply because I neglected to log into my Dropbox account for over a year, so my Dropbox account was automatically deleted in July 2016. Sorry for any inconvenience!

I probably shouldn't encourage people to use the old legacy versions of my setup kit. Certainly not yet. At some point I'm going to try to release many of my old-style setup kit scripts that I made since the last release in Feb. 2015 - but even I'm trying to get away from being stuck using any old-style version anymore, even my current best not-yet-released version.

I sure wish I could somehow gradually create a smooth transition from the old-style setup kit to the new-style setup kit I'm still trying to design and build. Or some kind of clever hybrid of the two.

Anyway, even though I'm quite tired of struggling with all these tedious legacy projects, I probably am not close to giving up yet. Or even if I do turn my attention to other things for a while, I'll probably return to them eventually.

In any case, please don't expect dazzling results soon, or maybe not for a very long time, and sorry I have been so incapable thus far of doing far more.

And I still don't feel up to trying to sift through whatever gigantic backlog of mostly spam (and perhaps some real emails) I might have gotten in the past several years, but, hopefully I'll get around to that someday. Sorry for being so unreachable.

And hopefully someday I'll figure out how to delete the literally hundreds of thousands of spam messages there are in the Non24.Com Forum without deleting any of the few non-spam messages, and also how to truly block new spam messages so the same thing doesn't happen again.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
How to make YouTube HTML5 audio work with Lighthouse 64 Puppy Linux 6.02 Beta 2 and a Sewell USB Sound Box
Monday, July 31st, 2017
08:40:30 GMT

Puppy Linux

I finally found a way to make YouTube's HTML5 player play audio while I'm using my Sewell USB Sound Box with Lighthouse 64 Puppy Linux 6.02 Beta.

Previously, I simply used the YouTube Flash Video Player web browser add-on instead of struggling to make the HTML5 player work. But, that add-on recently stopped working for me in the Pale Moon web browser. I tried upgrading Pale Moon, but that didn't fix the audio either.

But luckily, after a few days, I stumbled across this helpful forum thread. Post #10 contained all the info I needed. Thanks to all the authors of that thread!

Here's what I did:

  1. To get my Sewell USB Sound Box to work, I followed my own instructions here.

  2. I opened the text file /etc/asound.conf in a text editor. (You might want to make a backup copy of the asound.conf file in case anything goes wrong.)

  3. I replaced the entire contents of /etc/asound.conf with the settings from the above-mentioned Post #10:

  4. I closed then relaunched my web browsers - Pale Moon 27.4.1 and Firefox 45.0.2.

  5. I went to a YouTube video. Both audio and video played fine!

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
How to compile Pale Moon 27.4.1 from source code in Lighthouse 64 Puppy Linux 6.02 Beta 2
Monday, July 31st, 2017
11:35:28 GMT

Puppy Linux

Several days ago, after less than an hour of trying, I successfully compiled my favorite web browser, Pale Moon, from source code, in Lighthouse 64 Puppy Linux 6.02 Beta 2!

The reason I did that was because I thought upgrading my web browser might solve my issues with YouTube's HTML5 player not playing audio. (I was mistaken, but, I finally found a solution!)

And when I tried to simply download the latest precompiled version of Pale Moon for Linux, 27.4.0, it wouldn't run on my system because of this error. (Which also happened with at least one older version many months ago):

./palemoon: /lib/ version `GLIBC_2.17' not found (required by ./palemoon)

So, my only remaining option was to try to build Pale Moon from source code.

Since the build process was a bit more complicated than just ./configure; make; make install, and I thought I might need to know how to do it again someday, and that others might like to know too, I decided to document it.

Happily, it was a lot easier to build than I thought it might be. That was the first time I ever attempted to build a web browser from source code, and I was prepared to spend hours on it if I had to.

But, to my own surprise, it only took me about 45 minutes to figure out, thanks to various helpful web pages. And it will hopefully take much less time in the future, now that I've written this blog post, which even I will be able to refer to someday when I've forgotten most of the below details.

However, the below instructions will probably have to be modified if you don't have enough RAM, because the final /home/root/pmbuild folder on my system ended up being over 3 GB, or 3264 M, to be more exact.

And I was only able to build it there - a location inside my Puppy Linux RAM disk - because my current computer has a huge amount of RAM - 32 GB, which gives me a 16 GB Puppy Linux RAM disk.

So far, I wasn't able to figure out how to make the ./mach command build Pale Moon someplace other than /home/root/pmbuild. I'm guessing the best place to look for answers would be the official Pale Moon forum.

I also haven't tried these instructions in any other Puppy Linux, nor any other GNU/Linux. So, I don't know what changes might need to be made for other Puppies or GNU/Linuxes.

  1. I loaded the Lighthouse 64 DevX SFS file of development tools by right-clicking it and choosing "sfs_load".

    If you need a copy of the DevX SFS file, you can get it from here:

  2. I didn't have Autoconf 2.13, which is required to build Pale Moon, according to the official instructions on how to build Pale Moon in Linux.

    So, I downloaded autoconf-2.13.tar.gz from here:

  3. Then, I unzipped the autoconf-2.13.tar.gz in one of my temporary folders in my Puppy Linux RAM disk.

  4. Building Autoconf 2.13 was easy. In the autoconf-2.13 folder, I opened a terminal window and typed these commands:



    new2dir make install

    I put "new2dir make install" instead of "make install" because I wanted to make Puppy Linux .pet and .sfs installer files for Autoconf 2.13, so I hopefully wouldn't have to repeat this process again.

  5. I'm not sure this is necessary, but I moved my existing copy of autoconf (version 2.69) to some other location with this command:

    mv /usr/bin/autoconf /usr/bin/autoconf269

  6. Then, I had to make this symlink, or else the "Mach" software used to build Pale Moon complained that Autoconf 2.13 couldn't be found. This page gave me that idea:

    ln /usr/local/bin/autoconf /usr/local/bin/autoconf213

  7. Next, I downloaded the "" file from this page on GitHub:

    That file's size is about 230 MB.

  8. I unzipped "" in a temporary folder in my Puppy Linux RAM disk. (I went out of my way to put it in a path which contained no spaces, simply because lots of things in Linux seem to be allergic to spaces in paths.)

    If you don't have as much RAM as I do, you might want to unzip that folder to someplace on a physical disk.

  9. Inside the Pale-Moon-27.4_RelBranch folder, I had to put a text file named ".mozconfig" (without quotes).

    I copied and pasted the example .mozconfig file from the official instructions for how to build Pale Moon in Linux:

    But, I found I couldn't use exactly that, because the build got interrupted because I didn't have PulseAudio. And I much preferred to avoid installing PulseAudio because of its association with the infamous systemd.

    Fortunately, this forum thread gave me a clue of how stop Pale Moon from trying to use PulseAudio.

    Here's my final .mozconfig file, which you should place inside the "Pale-Moon-27.4_RelBranch" folder before the next step:

  10. I guess this is the point at which you might need to figure out how to change the default destination for the build, if your Puppy Linux RAM disk can't accomodate over 3 GB of files.

    As I mentioned before, I don't know how to do that yet - sorry.

    So, the rest of these instructions will simply assume you have enough RAM, as I did.

  11. Still in the "Pale-Moon-27.4_RelBranch" folder, I opened a terminal window, and typed this command:

    ./mach build

    Then, I just had to wait a while - 801 seconds, or 13.35 minutes. However, I was using a pretty good 2.8 GHz computer with 8 cores. So it might take more or less time depending on what you're using.

    I'm actually using a used Mac Pro from 2008, which looks like a giant cheese grater. :-) And I actually like it a lot, even though I usually prefer to avoid Apple products.

    Surprisingly, this Mac Pro can run Lighthouse 64 Puppy Linux 6.02 Beta 2, which makes it tremendously nicer for me to use than Mac OS X Lion does.

    The ./mach build command resulted in a large folder at /home/root/pmbuild/. I forgot to check its size before running the next step, but after the next step, it ended up being over 3 GB! 3264 M, to be more exact.

  12. There was still one more build command to run in the "Pale-Moon-27.4_RelBranch" folder:

    ./mach package

    This was much faster to finish than the build, and resulted in a tarchive quite similar to the official precompiled Pale Moon tarchives.

    That tarchive was in the folder /home/root/pmbuild/dist/ and named "palemoon-27.4.1.linux-x86_64.tar.bz2".

  13. Before you unzip that tarchive and run the "palemoon" file, you should probably take the precaution of backing up your current Pale Moon profile, just in case.

    In my system, by default, my Pale Moon profile is located at:

    /root/.moonchild productions

    To back it up, I close Pale Moon, and wait a little while to try to make sure Pale Moon is finished writing any files to that folder.

    Then I zip the folder, and put the zip file somewhere on a physical disk.

    I assume backing up the folder simply by copying the folder to a physical disk might also work, though I haven't tried that lately.

  14. Now, you can unzip the "palemoon-27.4.1.linux-x86_64.tar.bz2" file to whatever folder you want. It contains a "palemoon" folder which contains a "palemoon" executable file you can simply double-click on to run.

    That will launch Pale Moon 27.4.1 with your usual old Pale Moon profile, so, you hopefully won't have to reinstall your add-ons and other customizations from scratch.

    I upgraded from Pale Moon 26.2.2, and so far, I haven't noticed any problems with any of my old add-ons or anything else, though I haven't checked thoroughly.

  15. The most jarring difference I encountered was Google not being in the search engines list by default, but that is very easily fixed by clicking the Google link on this official Pale Moon Search Plugins page:

    And while you're there, you can add a lot of other handy search engines.

I'm very happy with my Pale Moon upgrade so far. It is noticeably faster than the old version I contentedly used for probably over a year, Pale Moon 26.2.2.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   Up ↑
Monday, July 31st, 2017
13:09:03 GMT


This is lovely:


by Mindaugas Piečaitis and Nora the Piano Cat.

You might also like to visit

   ▲ Top  ▼ Bottom  △ TOC   Up ↑


Note by Apollia on Nov. 8, 2023: Please join my Patreon if you'd like to support me and my work!

My main personal website is now I'm still not sure what to do with Astroblahhh.Com, so it's mostly staying as-is for now.