Posts Below
2/3/2016 - Part 4: My replies to the Free Software Foundation (FSF) Vision Survey (Activism)
2/2/2016 - No longer in Amazon affiliate program (Activism)
2/1/2016 - Part 3: My replies to the Free Software Foundation (FSF) Vision Survey (Activism)
2/1/2016 - Part 2: My replies to the Free Software Foundation (FSF) Vision Survey (Activism)
2/1/2016 - Part 1: My replies to the Free Software Foundation (FSF) Vision Survey (Activism)
1/20/2016 - Link: Free Software Foundation (FSF) Vision Survey (Activism)
1/19/2016 - Closed Source, Proprietary Food Products Are Bad Too (Health)
1/12/2016 - Pale Moon - a faster, more stable web browser than Firefox (Software)
1/10/2016 - Partway fixed a really bad glitch in multifiles-apmod.el (Emacs Lisp)
12/30/2015 - How to compile Guile-Gnome 2.16.4 in Lucid Puppy Linux 5.2.8 (Puppy Linux)
12/29/2015 - How to compile GNU Guile 2.0.11 in Lucid Puppy Linux 5.2.8 (Puppy Linux)
12/29/2015 - Was able to compile PHP 7.0.1 in Lucid Puppy Linux 5.2.8, but couldn't compile PHP-GTK 2.0.1 to work with PHP 7.0.1 (Puppy Linux)
12/27/2015 - Some thoughts on Lisp (Software)
12/27/2015 - How to compile newLISP in Lucid Puppy Linux 5.2.8 (Puppy Linux)
12/27/2015 - How to compile GNU Common Lisp 2.6.12 in Lucid Puppy Linux 5.2.8 (Puppy Linux)
12/15/2015 - Emacs Add-On: multifiles-apmod.el (Emacs Lisp - Add-On)
12/12/2015 - Links: Buffalo buffalo, etc. (Languages - English)
12/9/2015 - Links: "Lion-Eating Poet in the Stone Den" poem (Languages - Chinese)
12/4/2015 - Emacs Lisp code: Mouse-Clickable Search Results in Helm (with some glitches) (Emacs Lisp)
12/2/2015 - Emacs Lisp code: Right-Click to Highlight and Select Name - Sort of Like Notepad++ (Emacs Lisp)

Welcome to Astroblahhh.Com. This site, consisting of both blog and non-blog pages, features a gradually growing assortment of miscellaneous things on a variety of topics. I, the author of most of the stuff on this site, usually go by the name Apollia on the internet.

This blog was generated by the WordsPlatz blog software, which I wrote from scratch.


   ▲ Top  ▼ Bottom  △ TOC   ↓ Down
Part 4: My replies to the Free Software Foundation (FSF) Vision Survey
Wednesday, February 3rd, 2016
10:58:10 GMT


I forgot to post this before. The final part - part 4 of the replies that I was trying to send in response to the Free Software Foundation (FSF) Vision Survey.

Added to, edited, and reworded to some extent, with added HTML formatting and hyperlinks.

Part 1 - Part 2 - Part 3 - Part 4

(Quoted from survey:) Are there any social movements or organizations you would be excited to see us collaborate more with? (End of quote.)

Part 1 - Part 2 - Part 3 - Part 4

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
No longer in Amazon affiliate program
Tuesday, February 2nd, 2016
05:44:38 GMT


In the evening on Jan. 31, 2016, soon before I got started on trying to send my responses to the Free Software Foundation (FSF) Vision Survey, I found out I had received a mail on Jan. 31, 2016 at 1:28 PM from Amazon calling me a "Former Amazon Associate", and telling me about a payment of 65 cents.

My first Amazon affiliate payment ever! :-) (And last...)

I wondered (not very seriously) if Amazon had finally noticed that sometimes I link to Richard Stallman's page on Reasons not to buy from Amazon and kicked me out for that reason. :-)

But, it turned out that I had simply missed an email Amazon sent out in October informing affiliates they had to agree to some new thing, or get kicked out of the program.

Whoops. :-)

Anyway, I guess it's about time I finally left that program. I just lazily never bothered to quit, even though I removed hopefully all of my Amazon affiliate links maybe a few years ago (not sure when exactly).

The 65 cent payment wasn't even from anything recent. In my payment history, the date on that was 11/2/2011, and the transaction was "09/2011 Advertising Fees".

So, if you ever wondered how much money I ever made from being in the Amazon Associates program - now you know. :-)

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Part 3: My replies to the Free Software Foundation (FSF) Vision Survey
Monday, February 1st, 2016
12:22:54 GMT


Here's part 3 of the replies that I was trying to send in response to the Free Software Foundation (FSF) Vision Survey.

Added to, edited, and reworded to some extent, with added HTML formatting and hyperlinks.

Part 1 - Part 2 - Part 3 - Part 4

(Quoted from the survey:) Why is free software important to you? Why do you use it? (End of quote.)

I suspect my entire life might have gone better in many ways if I had learned more about free, libre software and hardware earlier in life.

And if I had had more access to those things earlier in life, I might have learned much more about programming a lot sooner, and thus had a better chance much sooner in life of being able to make a living.

And avoiding closed source, proprietary software and hardware would have probably saved my financially struggling family quite a bit of money over the years. But for a long time, none of us knew any better.

So, my family, including numerous children (including me, when I was a child) suffered in part because the closed source, proprietary software and hardware industry took advantage of my family's naive, ignorant willingness to buy their overpriced, liberty-infringing junk.

Problems caused by closed-source, proprietary junk also wasted a lot of all our time.

Still, I don't consider the closed source, proprietary software and hardware industries the most evil industries in the world.

Having closed source, proprietary software and hardware was at least better than having no software and hardware at all, and I did learn plenty despite the many inherent flaws of anything closed source and/or proprietary.

Being stuck with a Mac, and very frustrated with not being able to use a ton of software that was available for non-Macs, made me extra-fascinated with cross-platform things like the Inform 6 programming language.

I'm still pleased that I can actually still use things I wrote in the 90's in Inform 6 on any recent computer! :-)

Nowadays, there's also Inform 7, which is one of the most unusual and remarkable programming languages I know of.

A pity it's closed source despite being gratis.

It was probably good that even from a young age, I acquired a quite justified distaste even for non-libre shareware.

As a child with no good way to make money to pay for shareware (or most anything else), I felt quite unfairly persecuted by shareware which would do nasty things to try to force you to buy it, like make you waste time waiting for a timer to go away, or make you reinstall the software every 30 days, etc.

I didn't like to bother my family to buy me shareware (or anything), and I was so disgusted by those nasty sales tactics that even as a child, I actually became determined to never buy any shareware like that, even if I could ever afford to do so.

Even ordinary non-shareware proprietary software didn't annoy me as much back then, though I felt unfairly deprived of that too, because there was pretty much nothing I could do as a child to earn enough money to buy most anything myself.

But I guess the shareware annoyed me more because even when I was a child, it seemed so obviously unfair and mean for the shareware authors to go out of their way to build in nuisances to mistreat, annoy, and waste the time of unfortunate people (such as children like me) who were poor through no fault of our own.

I didn't need to be harassed into buying those often quite fun and useful (despite being non-libre) programs. In fact, at the time, I would have happily bought them all without being harassed if I simply had enough money, and hadn't been harassed.

Nowadays, of course, I'm not happy (or not entirely happy) buying anything which is closed source, or which threatens liberty in any other ways. But as a child, I didn't understand the importance of that stuff yet.

(I'm still not a total puritan, though. I enjoy my Roku, Netflix, and enjoyed the streaming music services MOG and Sony's Music Unlimited before both of them got closed down. But if there were adequate libre alternatives, I'd much rather use those.)

I am actually glad I had the chance to use HyperCard, even though I was too young at the time to figure out how to do anything very complicated with that.

Here's someone's interesting blog post on HyperCard:

HyperCard was actually really cool (except for being closed source and non-libre), and I think it's wonderful that HyperCard made it so easy for even average not-very-technical people to create their own software.

(Quoted from the survey:) If you have contributed financially/been a member in the past, but no longer do, why did you stop? (End of quote.)

I can't comfortably afford to remain a paying member. That's the only reason I didn't renew.

I'm pleased to see it's now possible to pay $10 a month instead of $120 all at once, but that's still too high for me.

(Quoted from the survey:) Care to elaborate on your answers, or give us any other positive or negative feedback? (End of quote.)

On the topic of the money I've made from software:

From Sept. 2007 to April 2008, I sold a closed-source software product called the MagnaMural in the virtual world game Second Life.

In April 2008, I released it into the public domain, partly inspired by this essay:

Why Software Should Be Free

I never kept very careful track of my sales, but, I estimate I probably made less than $10 USD total selling the MagnaMural.

But, sometime after I made the MagnaMural public domain, someone gave me an approximately $20 USD donation in Second Life, which is possibly the largest donation I ever got in Second Life. (I'm not sure if it was because of the MagnaMural or some other reason, because the person didn't send a note.)

Perhaps other donations I've received were at least partly inspired by my free/libre software, but hardly anyone sends me notes along with their donations, so I don't actually know the precise reasons why most people donated.

(But, thanks to everyone! Hopefully your support will be well-rewarded by my increasingly good software projects and other things that I'm still feverishly working on.)

Oh, and until the end of July 2011, I used to host someone's non-libre freeware on my website. (Well, one thing was non-libre, and the other was libre.) Someone sent me $15 because of that software, but that's the only donation I'm certain was inspired by that software.

In 2012, someone gave me a MacBook and iPhone, apparently in the hope I would use them to make a living writing iPhone or Mac software. Fortunately, I managed to resist the temptation. :-)

At least it was nice to find out that I wasn't really missing out on much of anything by being unable to afford Apple crap. I was surprised by how unimpressive the screen was, even though that particular MacBook was from 2009.

Another problem was, I couldn't even open that MacBook to take the hard disk or battery out because the bottom was screwed on with tiny unusual screws which ruined the two mini-screwdrivers I tried to use on them. Just awful, especially compared to how easy it is to take the batteries out of a Toughbook.

At least I was able to run Puppy Linux on it. But that still wasn't sufficient justification to keep it instead of selling it and getting some cheap old Toughbooks instead on eBay.

I often wish there was a freelance job website similar to, but which is exclusively for libre jobs.

I've glanced at, but, I don't know if I'm at a high enough skill level yet to even dare to try to undertake the astonishingly high-paying jobs I've seen on there. And if it turned out any of those jobs were non-libre, I would have to refuse to do them.

Also, I'd rather just do small things that I feel more sure I can handle.

Or actually, I'd rather just work on my own projects like the Puppy Linux Setup Kit, and yet somehow get paid.

A long time ago, I posted various hopefully helpful posts at the FSF's forum. Just thought I'd draw attention to them.

Part 1 - Part 2 - Part 3 - Part 4

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Part 2: My replies to the Free Software Foundation (FSF) Vision Survey
Monday, February 1st, 2016
10:37:15 GMT


Here's part 2 of the long replies that I was trying to send in response to the Free Software Foundation (FSF) Vision Survey.

Added to, edited, and reworded to some extent, with added HTML formatting and hyperlinks.

Part 1 - Part 2 - Part 3 - Part 4

(Quote from the survey:) Imagine it's 2020 and the opposite is true -- we are less free as computer users. Describe some things that have gone wrong. (End of quote.)

I find the Internet of Things very spooky - even now in 2016.

The "Internet of Things" and "Pervasive Computing": Some of the Worst Ideas Ever

Sometimes I wonder if we need not only the free software movement, but a free _from_ software movement. :-)

One of the most intriguing though worrying books I read in 2015 was Trillions: Thriving In The Emerging Information Ecology by Peter Lucas, Joe Ballay and Mickey McManus.

One reason I hope free (as in freedom), libre hardware will catch on a lot more is because I sometimes worry that maybe non-libre hardware manufacturers might somehow figure out how to make it totally impossible to even boot GNU/Linux on their hardware.

I wish I could 3D print my own computer stuff. :-D

I hope more can be done to financially support free, libre software authors, and everyone else in the world who could use more financial support.

Actually, I think there ought to be an unconditional basic income for everyone.

The only reason I'm able to write free, libre software at all is because my family supports me and doesn't try to treat me like a slave or try to force me to violate my ethical principles by writing closed source, proprietary software.

If I had happened to be in worse circumstances, the world would have missed out on quite a lot of my creations. (The best is yet to come. And much of it has probably been delayed a lot by my bad circumstances.)

Also, the stress, sometimes poor nutrition (which sometimes triggers headaches which might be migraines), and various other problems resulting from poverty also haven't been good for my health, so, I might have a shorter lifespan than I would have had if I had not been poor.

And maybe I'd be a less shy, timid person in general if I were in better circumstances. I probably would have pointed this survey out to more people, but I just felt too stressed out and overwhelmed to keep forcing myself to be outgoing (even on the internet).

Fortunately, posting things to my own websites, or sometimes even to very slow-paced quiet forums, is much easier for me than sending messages which will probably soon get a response which I probably ought to respond to promptly, but might be too stressed out, tired, headachy, etc. to feel up to dealing with or to even read.

At least usually avoiding the stress and time-consumption of social contact helps me focus and make more progress with my various projects sooner than I otherwise would.

Probably my software projects and perhaps some of my writing would do more to help the world (and even my own situation) than me having a social life, anyway. :-)

At least things are better than they were in the past. I'm very comforted by (among other things) my increasingly good programming skills, which give me some hope that somehow, someday, I might find a good way to make a living. Maybe even sometime before 2020. :-)

And perhaps I already could support myself if I had nothing against writing closed source, proprietary software.

If my family's financial problems had caused us to lose our home in 2013, it's unlikely I would have managed to finish a release of the Puppy Setup Kit back in Sept. 2014.

And if my family hadn't been struggling so much, I probably would have tried GNU/Linux many years sooner. I was curious to try it as early as 2002 - I just didn't have a spare computer to experiment with, and couldn't risk ruining my family's computer either. (Which, for many years, was a Mac, so probably no GNU/Linux would have worked on that anyway.)

I actually didn't even have a decent computer of my own until Feb. 2002. And, regrettably and with the naive optimism of youth (I was 20), I went into debt to get it.

Despite how unpleasant my life has been at times, I still have been very lucky. Financially, I'm much more trapped than people who can more easily work because they don't have severe sleep issues (and shyness) getting in their way.

But, unlike most people, I've had an unusually massive amount of free time, mostly thanks to my family supporting me. Which has been more valuable than money, I think, because I managed to put plenty - though far from all - of that time to good use.

But, sadly, probably tons of far more intelligent and talented people than me have not been so lucky.

And even many financially stable people have to spend a ton of their time slaving away at a job, time which they could probably devote to far more worthwhile pursuits.

I guess this is a good place to point out my Blog Action Day post from 2008.

Here's an interesting self-help blog post I stumbled across recently:

I also suggest reading the book Outliers by Malcolm Gladwell.

It's vitally important for people to have free time. And one reason why is because in general, probably no one becomes a world-class programmer or world-class anything else without tons of practice.

Another fascinating book I'd recommend is Antifragile by Nassim Nicholas Taleb.

Fragile things are damaged or broken easily. Robust things are resistant to damage and change. But antifragile things are things which actually benefit from rough handling, chaos, change, etc. Like a phoenix, or a hydra.

If you think about it, many closed source software business models might actually be pretty fragile, given that free, libre software and hardware of sufficient quality and ease of use could easily dissuade potential buyers of closed source, proprietary, liberty-infringing software and hardware from wasting any money on such things in the first place.

Another thing I'm concerned about is the systemd controversy. So far, I don't really understand it on a technical level, but, if I understand correctly, if too much software unrelated to systemd is made dependent on components of systemd, then, that could threaten people's freedom by making it much harder for people to build and run a GNU/Linux system without systemd.

And I've heard that incompatibilities caused by systemd dependence could make it difficult to compile free, libre software on non-GNU/Linux systems like BSD.

systemd is often referred to as "init software", but if I understand correctly, apparently it has grown far beyond just init software, and has been engulfing more and more basic functions traditionally done by many separate, independent components of GNU/Linux.

Here's the animation which introduced me to the systemd controversy:

And some other ones:


As a Puppy Linux user who doesn't even read the Puppy Linux forum very regularly, and also as someone who doesn't pay much attention to news in general (even Linux news), I just happened to avoid even noticing the systemd controversy for a long time.

But even the creator of Puppy Linux objects to systemd:

And there's this long Puppy Linux forum thread with mostly people objecting to systemd:

I'm very glad that this means that Puppy Linux will probably continue making a strong effort to remain free of systemd.

I'm also very glad the Devuan project exists.

Devuan is a fork of Debian, inspired by the fact that Debian was surprisingly overly welcoming of systemd and suppressive of people objecting to systemd.

Even though systemd is actually under a libre software license - the GNU LGPL 2.1+, according to Wikipedia - I suspect systemd really might be an insidious (though hopefully unintentional) threat to software freedom, since perhaps systemd might become so indispensable (due to software being made dependent on it) that it might become difficult to even build a GNU/Linux system or a lot of software packages without installing systemd.

On any computers with pitiful amounts of RAM I run Puppy Linux with (or any other computer), I don't want to be forced or pressured into having to waste RAM on anything at all that I can do without, but especially a reputedly big, bloated, overly complicated, tangled-up thing like systemd.

Or, quoting a description recently mentioned by someone on the Devuan mailing list - "the everything-welded-together, no-user-serviceable-parts-inside architecture of systemd".

So, I think it would be terrible if systemd somehow gets way too enmeshed in and almost (or totally) inextricably inseparable from GNU/Linux.

I hope long before 2020, that possible problem will be alleviated.

Also, I think it's really puzzling that some proponents of systemd seem to get so provoked by the fact that many people would prefer to avoid systemd.

One of the major benefits of using a libre operating system is that, unlike a closed source, proprietary operating system, you're supposed to be able to avoid having things you don't want being shoved down your throat.

So, I think the people objecting to having systemd practically forced on their systems are right to be upset, and the people who viciously mock and ridicule anyone who doesn't want systemd are (perhaps without realizing it) basically mocking and ridiculing software freedom itself.

Even if systemd were the best thing since sliced bread (which I don't believe it is), I think it would still be wrong to try to forcibly impose it on people who don't want it.

Part 1 - Part 2 - Part 3 - Part 4

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Part 1: My replies to the Free Software Foundation (FSF) Vision Survey
Monday, February 1st, 2016
06:13:30 GMT


I had some technical difficulties sending in my responses to the Free Software Foundation (FSF) Vision Survey at almost literally the last minute. Perhaps it was because my responses were so long.

Fortunately, I intended to probably post my replies on my blog anyway.

At least this gave me a chance to edit them a bit more and add some HTML. In fact, I'll probably even end up editing them after I post them, as I so often do with probably most things I post. (Edit, Feb. 1, 2016, 1:25 AM EST: Yep, definitely.)

I wrote so much that I'm splitting this into multiple blog posts.

Part 1 - Part 2 - Part 3 - Part 4

(Quote from the survey:) Imagine it's 2020 and people are more free and empowered as computer users, due to the efforts of the free software movement and the FSF. Describe some things that we have accomplished to reach this point. (End of quote.)

multifiles-apmod.el is an Emacs add-on I modified/enhanced a lot:

GNU Emacs, multfiles-apmod, and various other add-ons have been making it tremendously easier and more enjoyable for me to make progress with my various programming projects.

Even my previous favorite text editors (Notepad++ and Geany) were really getting in my way and slowing me down - so, if I hadn't switched to Emacs, I think all my projects might've gotten substantially delayed, and I might even have given up on some of them.

Even though it took me almost 2 months of almost daily effort to get cozy with Emacs, I think it will save me quite a lot more time than that in the long run.

So, by 2020, I suspect I will have completed more projects and done a much better job of building them than I would have if I hadn't gotten cozy with Emacs, and hadn't enhanced the multifiles add-on.

And the VUE concept mapping software also continues to help me:

I've been using VUE since 2010 already (or maybe even longer, I can't remember) to make notes, flow charts, etc. It's a great tool for brainstorming and trying to design software, and helps me get a nice, visual overview of things and how they relate to each other.

I plan on using it for publicly-released documentation in the future, rather than just my own private notes.

Sometimes I think things like news articles could benefit from being in a VUE-like concept-map format.

It might make ideas easier to absorb at a glance than conventional articles which might describe numerous complicated ideas in big blobs of text, without visually showing how different things link together or otherwise interact or relate.

For a long time I've wished I could edit actual code itself (rather than just notes about code) using VUE.

A few months ago I heard about a program called Code Bubbles. I still haven't tried it yet, but, I think Code Bubbles is probably the closest thing I've ever heard of so far to my daydream of being able to use VUE to edit actual code.

I've been thinking maybe using XSLT on the XML source code of a VUE file might be able to transform a VUE file containing source code text into actually runnable (or otherwise useable) source code files.

So maybe my daydream would be easier to implement than I thought.

But VUE still wouldn't have syntax coloring and a ton of other nice features of a normal code editor.

I wish I could embed little Emacs editors inside of VUE nodes. :-)

I'm guessing Emacs probably already can run in the Java Virtual Machine somehow, and VUE is free, libre Java software, so, maybe that wouldn't be totally unfeasible. :-)

One of the most exciting things I found out about in 2015 was graph database software, which is reputed to typically be much faster and easier to work with than conventional relational databases.

I still haven't done much with graph databases myself yet, but, I'm looking forward to eventually experimenting more with OrientDB and perhaps Neo4j.

The Neo4j website is currently offering free (as in price) copies of their O'Reilly book on graph databases:

Graph databases are another thing I wish I could use VUE as a GUI to work with them.

I haven't yet gotten deeply into learning Lisp, but, I still want to because of what I've read about it possibly being the overall best, most powerful programming language in existence.

I'm greatly looking forward to reading Paul Graham's book On Lisp, which is legally downloadable from his website:

Maybe by 2020, I'll be primarily a Lisp programmer instead of mostly a PHP, Perl, JavaScript, MySQL, SQLite, and Bash programmer.

Emacs, multifiles-apmod, other Emacs add-ons, and VUE have been helping me renovate my Puppy Linux Setup Kit:

I'm working on making the kit more flexible and easy to update, though it already works remarkably well and has saved me a ton of time.

My Puppy Setup Kit makes it so I can go from a totally uncustomized Puppy Linux system to a system customized exactly the way I like it, in just minutes, by clicking a single script.

My setup kit also makes it so I'm not so dependent on having to use a specific computer with a specific hard disk, since I can mostly or completely replicate my entire comfortably customized system in minutes on quite different computers.

Though sometimes I need to adjust the kit a bit to make that work right, like when I switched to a laptop and then found I had to add some new stuff to make the touchpad work the way I liked.

But once I've finished any necessary adjustments, then, from then on, setting up my system is nearly effortless - I just have to click a single script, click a confirmation dialog box, wait a few minutes, and press Enter every once in a while.

(And it would be pretty easy to make some Puppy Setup Kit construction plans which require no user input at all beyond opening one script and clicking one confirmation dialog box.)

In the past, when I used an operating system (Windows) installed on an internal hard disk, my computer seriously breaking down tended to be an incredibly stressful disaster, which sometimes took days, weeks, or once over a month to recover from, due to having to struggle to fix whatever broke, and sometimes having to struggle to acquire another computer and then reinstall everything from scratch.

And I always absolutely dreaded having to open up my computer for any reason, such as to get the internal hard disk out so I could try to rescue any unbacked-up data.

But now, hard disks are optional for me. And if any of my computers ever totally breaks down, I can move to a different one almost seamlessly. I love it!

I love it so much I won't even seriously consider going back to relying on any OS installed on a hard disk - not even a GNU/Linux! - because I find it far too easy to accidentally ruin even my GNU/Linux systems by installing things I shouldn't have installed.

I never want to return to having to struggle to fix things like that. With my Puppy Setup Kit, all I have to do to get everything back to normal is just reboot, and run my setup kit again.

One of the things that deterred me from even trying GNU/Linux for years was being afraid of accidentally ruining my Windows installation by installing GNU/Linux on the same hard drive.

Probably lots of Windows and MacOS users are afraid of that.

So, I didn't try GNU/Linux until I found out about live discs, which I think I first heard about in 2006 because I was desperately searching for a way to rescue data from a broken-down Windows system.

I still didn't end up switching to GNU/Linux until 2011, though. I was pushed into it due to the fact that my hard disk was making odd little noises, which made me think, maybe I should use a Puppy live disc for a while so I can avoid making my hard disk work too hard until I can afford to get a replacement hard disk.

But when I found Puppy was so delightfully fast, and so nice to use just from a live disc without even having to install it, I found I actually didn't even want to go back to using primarily Windows again.

Windows XP was actually reasonably fast on that computer, but Puppy was (and still is) so fast it made Windows seem annoyingly slow in comparison.

Before I made my Puppy Setup Kit, I used to use Puppy's really cool built-in ability to save your custom settings, installed programs, etc. on the Puppy live CD or DVD you booted your computer with just by writing additional sessions to the disc.

But the more sessions you have, the slower it becomes to boot, so, eventually, I decided, instead of saving minor settings changes to my disc, I'd just use some Perl scripts to adjust my settings.

Thus, my Puppy Setup Kit was born.

I think my way of using Puppy is probably still unconventional even amongst Puppy users (partly since I still haven't gone to much trouble to tell the world about my setup kit because I think I should renovate it first).

But, this is my favorite, most comfortable computer setup ever. I finally don't have to live in as much fear of my hard disk or computer breaking down, because it's so simple now to just switch to another computer and have everything be pretty much the same.

And Puppy, running in a RAM disk, is the fastest OS I've ever used. Even a 1.5 GHz single core laptop with only 2 GB of RAM running Lucid Puppy 5.2.8 version 004 seems tremendously faster than the single core 2.0 GHz 1 GB RAM Windows Vista computer of someone I know, which frequently gets stuck for minutes on end on things that Puppy does in literally seconds, like opening programs or going to certain web pages.

Once my Puppy Setup Kit is renovated, it will be a lot easier for me to share my current exact setup with anyone who wants to try it, and also for me (and hopefully anyone) to add to the kit to make it possible to easily install whatever sets of software and settings anyone wants to install.

So, maybe I'll finally be able to persuade some of the more stubborn Windows and Mac users I know to try Puppy. And with the renovated Puppy Setup Kit, hopefully everyone (including me) will have a much easier time customizing our own Puppies to work exactly the way we want.

(I'd actually like it if the Puppy Setup Kit could work with any GNU/Linux live disc as well as Puppy, but, I'm not up to trying to build that just yet.)

I'd also like to make it possible to write Puppy Setup Kit scripts in any language, not just Bash or Perl.

Not sure yet how to do that, but, maybe if I store details about installable software, settings, etc. in JSON files, that will make the data accessible by most languages.

Another goal of mine with the Puppy Setup Kit is to build something like what I was writing about package management around the end of this blog post:

I think it would be good if people were less dependent on downloading precompiled binaries via package manager software.

It's always good to know how to do things yourself rather than having to depend on other people to do things for you. And it's also safer to compile things from source code rather than to just trust that the package builder and/or the repository are trustworthy/uncompromised.

Plus, things compiled from scratch conceivably might work better for you because of being tailored to your exact system, instead of the possibly quite different system of whoever built a package.

So, I think it would be good if more people learned how to compile things themselves from source code, and also would be good if people had some partially automated tools to help with the boring, automatable parts of the process of compiling your own package from source code.

After writing the above blog post, I found out that Gobo Linux has a really cool "recipes" feature which already seems to do much of what I had in mind. (Haven't tried it myself yet, but want to...)

Gobo Linux's reorganized directory structure is quite interesting too:

And NixOS also seems to contain some interesting ideas:

Having partially-automated build-your-own-packages-from-source capabilities in the Puppy Setup Kit will pave the way to me being able to easily release an update of Astroblahhh GLMP-GTK and Astroblahhh PH-GTK:

...and thereby also make it possible for people to easily install and use the not-yet-complete renovated version of Astroblahhh Desktop, among other things.

The build-your-own-packages-from-source features will also make it possible for me (and/or others) to help popularize things like (for example) GNU Guile by making them extremely easy to compile from source and install.

Recently, I was very pleased to hear about the $5 version of the Raspberry Pi.

I'd be very interested to see a list of cool cheap hardware gizmos which the FSF approves of.

One reason I haven't gotten a Pi yet is because in my experience, 512 MB of RAM is far too little to run Puppy Linux the way I want, with the entire OS and all my installed software loaded into RAM. On my 512 MB RAM computer, I can't install much software, and it's quite prone to totally freezing up with no way to fix it other than restarting. (But the same computer is capable of a lot of cool things with an OS installed on its hard disk.)

1 GB is a bit better (and even good enough to run a Windows XP VirtualBox reasonably well, at least if VirtualBox is almost the only thing you install), but that still forces me to make difficult choices amongst what software I want to install, and I have to reboot to install different sets of software and settings.

2 GB of RAM is sort of OK, but I much prefer 4 GB or more. The more, the better. So, I'd much prefer to get a small cheap Pi-like gizmo with a lot more RAM than a Pi.

And, after all the distressing things I read about systemd, I was very happy to hear about the Devuan project:

I'm also very happy that Puppy Linux is also systemd-free and will hopefully stay that way.

(The rest of my survey replies will be in future blog posts.)

Part 1 - Part 2 - Part 3 - Part 4

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Link: Free Software Foundation (FSF) Vision Survey
Wednesday, January 20th, 2016
00:29:29 GMT


The Free Software Foundation (FSF) is doing a survey until the end of January 2016:

Free Software Foundation (FSF) Vision Survey

And here's the blog post about the survey.

The FSF is also trying to raise $450,000 by January 31st, 2016. They're already most of the way there - as I write this, it says "370,295 so far" at the top of this page.

Addition, Feb. 3, 2016, 6:11 AM EST. Here are my responses to the survey:

Part 1 - Part 2 - Part 3 - Part 4

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Closed Source, Proprietary Food Products Are Bad Too
Tuesday, January 19th, 2016
12:16:44 GMT


As I've so often pointed out, closed source, proprietary, non-libre software is inherently flawed in a lot of ways.

But one thing I haven't pointed out as often is that closed source, proprietary, non-libre food products also are inherently flawed in a lot of ways.

Over the years, many products I used to like have either gotten totally discontinued (either arbitrarily or because the company went out of business), or their secret, proprietary, closed source recipes have been changed against my wishes.

And I wish there was more information available about the precise origins of every ingredient in my food.

This blog post was inspired by the fact that I recently found out I can no longer have my preferred version of yet another product I used to like - the Rite-Aid brand nutrition shake, a knock-off of Ensure.

I originally switched to the Rite-Aid nutrition shake after the real Ensure's recipe got changed in a way that tasted bad to me.

So, I'm particularly annoyed that even my favorite alternative to Ensure has now been ruined for me.

To my dismay, I recently found that Rite-Aid's vanilla-flavored "Original" nutrition shake now contains "liquid sucralose". (Luckily I noticed this before I drank any.)

I've read some very worrying things about sucralose (also known as Splenda), so, I can't possibly drink that variety of Rite-Aid nutrition shake ever again unless the makers get rid of the sucralose.

I found a Rite-Aid "Plus" vanilla nutrition shake which had sugar instead of sucralose, but, it doesn't taste as good as the kind of Rite-Aid nutrition shake I used to like (which I think was the vanilla-flavored "Original" kind, before its recipe was ruined with sucralose and who knows what other changes), which I assume they probably don't even make anymore.

The kind they used to make actually tasted better to me than Ensure ever did.

Anyway, this all would be less of a problem if the recipes of these products weren't probably secret and proprietary.

If all food products had free (as in freedom), libre, open source recipes, it would be impossible for the makers of those products to permanently deprive their customers of the customers' preferred versions of those products, because the makers wouldn't have a monopoly anymore.

So, people would no longer be dependent on the only maker of an exclusive product to never discontinue their product, to never tamper with the recipe, and to never go out of business.

Another problem with the "closed source" food industry is vague, uninformative ingredient names such as "natural flavors" and "artificial flavors".

But even not-so-vague ingredient lists are still inadequate, because I'd like to know not only what is in my food, but everything there is to know about the origins of each ingredient.

Did any ingredients possibly come from a farm or other location which is overly close to a hydraulic fracturing (fracking) well, a toxic waste injection well, or other hazardous abomination? (I've been wondering about this ever since watching the documentary Gasland.)

Are there any genetically modified (GMO) ingredients? Exactly what pesticides were used? Were all the employees paid well and treated well? Etc., etc.

Even if all that information can't fit on a food label, at least it could be put on the web.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Pale Moon - a faster, more stable web browser than Firefox
Tuesday, January 12th, 2016
06:20:36 GMT


About 2 weeks ago I finally got tired of Firefox 32 being overall slower than it should be, and too often completely crashing my entire system, which forces me to reboot, and go out of my way to avoid certain websites or pages while using one of my main Linux systems. (A rather pathetic single-core 1.5 GHz laptop with 2 GB of RAM, running Lucid Puppy Linux 5.2.8 version 004.)

Unfortunately, when I updated to the latest Firefox in the hope that it might be better than Firefox 32, I found it seems to no longer be possible to change Firefox's horrible new search interface back to the far nicer old search interface, which lets you change the default search engine with two clicks.

That was the final straw for me, so I finally tried Pale Moon (version 25.8.1), a free (as in freedom), libre, open source web browser forked from Firefox.

Pale Moon's source code is available on GitHub. (I actually didn't try compiling it from source yet, but someday I probably will.)

Even on my 1.5 GHz laptop with 2 GB of RAM, Pale Moon is refreshingly faster and more difficult to crash than Firefox 32 and any later version of Firefox I briefly tried. Pale Moon has my preferred search interface, and other defaults I prefer, right out of the box.

Pale Moon is even compatible with my favorite Firefox add-ons - NoScript, Stylish, Web Developer, NoSquint, and even the add-on I modified myself.

In the past couple weeks of using Pale Moon on my 1.5 GHz laptop with 2 GB of RAM, I only crashed my entire system once, probably only because I was recklessly trying to test Pale Moon's limits by opening way more tabs than I ordinarily would have dared to with Firefox.

Overall, Pale Moon crashes much less often and less severely for me than Firefox. Usually the worst thing that happens is, Pale Moon sometimes suddenly closes, but I can get all my tabs back just by reopening Pale Moon. And I can usually avoid that kind of crash by avoiding opening tons of tabs.

So, I just thought I'd recommend Pale Moon, since so far, it seems really great, fast, and much better than Firefox has been lately.

Addition, Jan. 12, 2016, 3:57 AM EST. I also tried - or tried to try - GNU IceCat, but, it wouldn't launch for me at all while running Lucid Puppy Linux 5.2.8 version 004, since apparently I don't have "GLIBC_2.17". But I'll certainly try GNU IceCat again if I ever switch to a newer Puppy Linux.

I also have read good things about SeaMonkey, but haven't tried it recently, mostly because I don't need any of its features besides a web browser, and conserving RAM is important if you're running Puppy Linux on a computer with too little RAM. I guess 2 GB of RAM is tolerable, but 4 GB or more is much better.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Partway fixed a really bad glitch in multifiles-apmod.el
Sunday, January 10th, 2016
22:18:04 GMT

Emacs Lisp

Today, I discovered and partway fixed a really bad glitch in multifiles-apmod.el, and updated multifiles-apmod.el to version 2.0.

This glitch is terrible enough for me to post this whole new blog post just to draw attention to it and encourage people to update to the safer - though still only partway fixed - version 2.0.

I don't know if I'll be able to fix it completely in the near future, and there could always be other problems that I don't even know about yet, so, please be careful.

The glitch is avoidable if you don't make any of your embedded buffers or files read-only - but ideally I'd like to somehow make it impossible to run into this glitch at all.

Quoted from the Readme:

This version partway fixes a REALLY bad glitch I discovered today. The glitch is caused by editing read-only buffers in a multifile, which somehow messes up the mirroring in ALL multifiles (even multifiles you weren't editing and which don't contain read-only buffers), and makes it impossible for ALL multifiles to save their embedded files.

This has been partly fixed by making it so read-only buffers are blocked from being added to a multifile when a multifile is first being built.

However, I don't yet know how to make it impossible to make the embedded buffers read-only after they've been added to a multifile. So, unfortunately, it is still possible to run into this horrible glitch accidentally, such as by going to the original buffer of an embedded buffer, and clicking the asterisk at the left of your modeline which toggles whether the buffer is writable or read-only.

And to make matters worse, because the mirroring of ALL embedded files in ALL multifiles gets messed up by this glitch, Emacs probably won't even ask you at shutdown if you want to save even the writable embedded files you edited!

So, please be careful. If you do run into this horrible problem, then, to save your data, you can copy and paste the entire contents of your multifile into another buffer and save that buffer, which will create one large combined file. Sorry, I don't know of an easy way to merge the changes in that large combined file back into your separate files.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
How to compile Guile-Gnome 2.16.4 in Lucid Puppy Linux 5.2.8
Wednesday, December 30th, 2015
14:39:36 GMT

Puppy Linux

It was another difficult process, but I finally managed to build Guile-Gnome for GNU Guile in Lucid Puppy Linux 5.2.8 version 004.

Now, I can actually make GNU Guile create GTK windows! So, perhaps GNU Guile will turn out to be a good substitute for PHP-GTK.

If I can get GNU Guile to work with MySQL and SQLite databases, and also have it output web pages (so I can keep Astroblahhh Desktop's web interface), perhaps a GNU Guile-based Astroblahhh Desktop might be feasible.

I wonder if GNU Guile can work with OrientDB?

However, I'm not sure if I should write the CMS (content management system, for lack of a better term) of my dreams in any very uncommonly used language or platform. PHP is available from most web hosts. Even figuring out how to make the Java-based OrientDB work with my websites seems like it might be difficult, though maybe less difficult than figuring out how to get some form of Lisp or Scheme like GNU Guile working on a web server.

But, back to the topic of how to build Guile-Gnome in Lucid Puppy Linux 5.2.8 version 004.

Once again, I had to use some trickery (or guile! Haha, I made a pun) to get past some hopefully mistaken errors. I'll explain more about that below.

  1. The first prerequisite is to build GNU Guile, if you haven't already. This earlier blog post of mine has instructions.

  2. You can download Guile-Gnome itself here:

    I used version 2.16.4.

  3. Guile-Gnome has various dependencies that you'll need to download.

    Here's most of what I needed:

    Those are the three easiest things to get. Downloading Guile-Cairo will be explained in step 3.

  4. Guile-Cairo can't so easily be downloaded because the needed version was never officially released - it seems to only be available by downloading it via Git (and not even GitHub).

    Fortunately, an at least partway functional copy of an old version of Git exists in the Lucid Puppy Linux DevX SFS file of development tools. The DevX, by the way, is what you need to use to compile software in Lucid Puppy Linux 5.2.8.

    My page of Some Puppy Linux Basics explains more about DevX files, and if you need the DevX for Lucid Puppy 5.2.8, it's available at this link:

    (If you're using a different version of Puppy than Lucid Puppy 5.2.8, that DevX probably won't work, so you should instead download the DevX released for your Puppy.

    Also, if you're not using Lucid Puppy 5.2.8, please bear in mind that the instructions in this blog post might not all apply or work for you, since different Puppy Linux distros, and probably even different versions of the same Puppy distro, can differ quite substantially from each other.)

    And here's how to load SFS files.

  5. Once you have the DevX mounted, you should be able to run Git. Go to a folder that you want to download Guile-Cairo into, open a terminal window, and put in this command:

    git clone git://

    If it worked, you'll see some text like this:

    # git clone git://
    Initialized empty Git repository in /root/guile-cairo/.git/
    remote: Counting objects: 830, done.
    remote: Compressing objects: 100% (280/280), done.
    remote: Total 830 (delta 522), reused 830 (delta 522)
    Receiving objects: 100% (830/830), 594.72 KiB | 666 KiB/s, done.
    Resolving deltas: 100% (522/522), done.

    And there will now be a "guile-cairo" folder in the folder you opened the terminal window from.

  6. Now we can get started compiling things. First, an easy one. Unzip the G-Wrap source code tarball, open the G-Wrap folder, open a terminal window, and put in these commands:



    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  7. Next, Pixman, which is also easy to compile. Unzip the Pixman source code tarball, open the Pixman folder, open a terminal window, and put in these commands:



    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  8. Next, a more difficult one to compile - Cairo. Unzip the Cairo source code tarball, open the Cairo folder, open a terminal window, and put in these commands:

    export pixman_CFLAGS="-I/usr/local/include/pixman-1"

    export pixman_LIBS="-L/usr/local/lib/ -lpixman-1"

    ./configure --enable-gobject=yes


    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  9. Next, Guile-Cairo. Mostly easy, once you have Cairo itself compiled correctly.

    If you want to make a .pet or .sfs file, rename the Guile-Cairo folder to something like "guile_cairo-1.10". (Though I'm not sure that's the actual version number. You can use any version number - this rename is just to make it so new2dir won't complain later on about not being in a folder with a version number.)

    Next, open the Guile-Cairo folder, open a terminal window, and put in these commands:

    ./configure --prefix=/usr/local


    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  10. Now, it should be possible to compile Guile-Gnome itself. Unzip the Guile-Gnome source code tarball, open the Guile-Gnome folder, open a terminal window, and put in this command:

    ./configure --prefix=/usr/local/

    If all went well, somewhere in the messages printed by ./configure should be this text:

    All available wrappers will be built:
      atk cairo corba gconf glib gnome-vfs gtk libglade libgnome libgnomecanvas libgnomeui pango

  11. Don't type "make" yet. Here's where I had to do a maybe unwise trick, so Guile-Gnome won't complain that "Cairo was not compiled with support for GObject".

    Go to the folder /usr/local/include/cairo/ and open the file cairo-gobject.h in a text editor.

    Delete this line toward the top (line 42 in my cairo-gobject.h):


    And delete these three lines near the bottom (starting at line 188 in my cairo-gobject.h):

    # error Cairo was not compiled with support for GObject

    Then, save the cairo-gobject.h file.

    I believe that due to the way I compiled Cairo (described above), Cairo really does have GObject support.

    And also, I got an encouraging-looking response when I tried a command I found on this page:

    pkg-config --libs cairo-gobject

    The response was:

    -pthread -L/usr/local/lib -lcairo-gobject -lcairo -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0

  12. Now, back in the Guile-Gnome folder's, type this in a terminal window:


    Hopefully everything will go smoothly now that Guile-Gnome has no way not to acknowledge that Cairo really does have GObject support.

  13. Next, type either "make install" (without quotes) or "new2dir make install" if you want to make a .pet or .sfs file out of Guile-Gnome.

  14. For some reason, GNU Guile doesn't automatically know where the Guile-Gnome modules are, so you have to give GNU Guile this command:

    (use-modules (gnome-2))

    After doing that, it should be possible to run the example scripts from the Guile-Gtk Overview page, which will create a GTK window containing a button which says "Hello, World!"

I don't know yet how to make GNU Guile automatically find the Guile-Gnome modules.

But, I assume that similar to GNU Emacs, there's probably some sort of config file somewhere which you can put commands in like "(use-modules (gnome-2))" so those commands will be run automatically every time you start GNU Guile.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
How to compile GNU Guile 2.0.11 in Lucid Puppy Linux 5.2.8
Tuesday, December 29th, 2015
13:07:46 GMT

Puppy Linux

I apparently managed to compile GNU Guile in Lucid Puppy Linux 5.2.8 version 004 - though doing so was even more difficult than the last few things I compiled.

And I'm not sure the way I did it was a good idea, since I had to do something rather questionable to trick libunistring into acknowledging that my copy of iconv works. I hope this didn't break anything, but I have no idea. So, please be careful.

I got interested in GNU Guile because it uses the programming language Scheme, which is related to Lisp, and GNU Guile has a component called Guile-Gnome (which I haven't tried to compile yet) which apparently lets you deal with GTK stuff.

So, I guess basically I'm fishing around for Lisp-y alternatives to PHP-GTK, just in case I turn out to like Lisp or maybe even Scheme more than PHP.

But maybe in the end I'll just use lisphp with PHP and PHP-GTK. Or maybe I won't even like Lisp enough to do that? I just haven't done enough with any Lisp or Scheme yet to be able to decide.

Also, another factor to take into consideration is, how cross-platform are these Lisp and Scheme-based things? Will they make it as easy as PHP-GTK to make Astroblahhh Desktop capable of working in not only Linux, but also Windows and Macs?

How to build GNU Guile in Lucid Puppy Linux 5.2.8 version 004:

  1. There were at least two dependencies of GNU Guile I had to download, compile and install - libunistring (I used version 0.9.5), and libgc (I used version 7.2).

    And if I hadn't already had libffi 3.2.1 as a result of compiling newLISP the other day, I probably would have had to install libffi too.

    So, the first step is to download the dependencies you need:

  2. Lucid Puppy 5.2.8 version 004 apparently already has iconv - so, I'm not sure if this step 2 is necessary. But, I upgraded to libiconv 1.14 in the hope that that would get rid of libunistring's refusal to acknowledge that I have a working copy of iconv.

    But, even upgrading libiconv still didn't fix that problem, so I had to resort to something which I'm hoping was not a bad, dangerous thing to do - I edited libunistring's configure script to make it just assume iconv is working. (I'll explain exactly what I did in a later step.)

    I don't know whether or not GNU Guile can use the iconv that comes with Lucid Puppy 5.2.8, so, maybe it's best to upgrade to libiconv 1.14, as I did.

    So, step 2 is to download libiconv, if you want to update iconv.

  3. And, download the source code of GNU Guile itself. (I used version 2.0.11.)

  4. Unzip the libffi source code tarball, open the libffi source code folder, and open a terminal window. Then, do these 3 commands:



    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  5. Next, unzip the libgc source code tarball, open the source code folder, open a terminal, and do these commands:



    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  6. If you decided not to upgrade libiconv, you can skip this step.

    If you decided to upgrade libiconv, unzip the libiconv source code tarball, open the libiconv code folder, open a terminal window, and do these commands:

    ./configure --prefix=/usr/local


    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

    Then, to stop your system from trying to use the old iconv instead of the new iconv - go to the folder /usr/bin, and rename the file iconv to something else.

  7. Next, unzip the libunistring source code tarball, and open the libunistring source code folder.

  8. This is the trickiest and probably the most potentially dangerous and questionable step. I'm not sure this is a good idea at all, but, I haven't yet found any other way to make the build of GNU Guile succeed, because GNU Guile's ./configure complains if libunistring is compiled without libiconv support.

    In the libunistring source code folder, open the file "configure" with a text editor. Go to line 17639, which says:


    Change it to:


  9. Next, open a terminal at the libunistring source code folder. Do this command:

    ./configure --prefix=/usr/local

    If it worked properly, it should say the following starting around line 114 of the stuff printed by ./configure:

    checking for iconv... yes
    checking for working iconv... yes
    checking how to link with libiconv... /usr/local/lib/ -Wl,-rpath -Wl,/usr/local/lib
    checking for iconv declaration... 
             extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
    checking for iconv.h... yes

    If it does say that, then, do these commands:


    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.)

  10. Now that GNU Guile's dependencies have been installed, we can proceed with building GNU Guile. Unzip GNU Guile's source code tarball, open the GNU Guile source code folder, and open a terminal window. Do these commands:



    (The first line somehow stops "make" from complaining about not being able to find libunistring.)

  11. Next, do this command:


    And be prepared to wait a long time for it to build. For me, it took more than a half an hour, even on the 3.4 GHz dual core desktop computer I was building it on.

    At first it looks like it's going pretty fast and doing lots of stuff, but it seemed to get stuck for a very long time doing something with these files:

    wrote `ice-9/eval.go'
      GUILEC ice-9/psyntax-pp.go
    wrote `ice-9/psyntax-pp.go'
      GUILEC ice-9/boot-9.go
    wrote `ice-9/boot-9.go'
      GUILEC ice-9/vlist.go
    wrote `ice-9/vlist.go'
      GUILEC srfi/srfi-1.go
    wrote `srfi/srfi-1.go'
      GUILEC language/tree-il/peval.go
    wrote `language/tree-il/peval.go'
      GUILEC language/tree-il/cse.go

    And so on. I was a bit worried something went wrong and it was never going to finish, but, all I had to do was wait. And wait, and wait.

  12. Once "make" is finished, you can do this command:

    make install

    (Or, if you want to build an .sfs or .pet file, put "new2dir make install" (without quotes) instead of "make install".)

Now, it should be possible to run GNU Guile simply by typing "guile" in a terminal.

I don't know if there's a GUI (graphical user interface) somewhere, but, if I find there is, I'll update this post.

I don't yet know how to make GNU Guile do anything particularly eye-catching, but, you can make it do some addition by typing something like this:

(+ 2 2)

To which GNU Guile will respond:

$1 = 4

And apparently that creates a variable called $1, containing "4" (the result of adding 2+2).

And you can use the automatically-created $1 variable in other commands like this:

(+ $1 1)

To which GNU Guile will respond:

$2 = 5

($1 equals 4, and 4 plus 1 equals 5.)

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Was able to compile PHP 7.0.1 in Lucid Puppy Linux 5.2.8, but couldn't compile PHP-GTK 2.0.1 to work with PHP 7.0.1
Tuesday, December 29th, 2015
06:50:38 GMT

Puppy Linux

I finally heard the news that PHP 7.0.1 has been released. So, I decided to see if I could get PHP-GTK 2.0.1 working with it. Alas, no.

I had hardly any trouble compiling PHP 7.0.1 itself. The only problem I had was this old problem, oddly deemed "Not a bug", from 2010:

./configure got stopped with these error messages at the bottom:

The problem was, I had put my PHP source code folder at a path which had a space in it:

/apmnt/truecrypt62/Hobbiton_Meadow/PHP 7/php-7.0.1/

I think I encountered this error while compiling PHP in the past, but I forgot yet again that lots of things in Linux have ridiculous incompatibilities with paths containing spaces.

The fix was simply to remove the space, changing the path to this:


"./configure" worked fine after that, and so did "make" and "make install".

Here are some details on what stopped me from compiling PHP-GTK 2.0.1 to work with PHP 7.0.1.

If I recall correctly, PHP-GTK 2.0.1 needs the Cairo extension from PECL, and I wasn't able to compile Cairo 0.3.2, despite the fact that it worked with PHP 5.6.13.

This is as far as I got trying to compile Cairo 0.3.2:

And this is as far as I got trying to compile PHP-GTK 2.0.1:

So, if I ever manage to finish the PHP-GTK version of Astroblahhh Desktop, it might not be capable, at least for a while, of running on anything much newer than PHP 5.6.13. (Though it might also work with slightly later versions of PHP 5.6 which I haven't yet tried.)

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Some thoughts on Lisp
Sunday, December 27th, 2015
17:12:56 GMT


I'm still unsure about whether all the claims about the Lisp programming language being incredibly great, and more powerful, flexible, and overall better than any other language are really true or not.

But, hopefully I'll find out, now that I have GNU Common Lisp and newLISP to play with, in addition to the GNU Emacs editor.

Some Emacs Lisp code is very readable. For example, the command (beginning-of-line), which moves your cursor to the beginning of the line. :-)

But with much other Emacs Lisp code, I wasn't sure at first if I found Bash or Emacs Lisp more confusing and indecipherable. Fortunately, working on multifiles-apmod.el helped me get increasingly used to Emacs Lisp, and I definitely at least like it more than Bash now.

For me, Lisp is a lot more readable and understandable when I use my preferred indentation style rather than the confusing styles I've seen everywhere else.

I really appreciate that Lisp doesn't care what formatting I use. One of the reasons I'm never going to be able to tolerate the Python programming language is because of Python's strict enforcement of some quite irritating rules about formatting.

I usually am pretty consistent with my indentation style, but sometimes for boring but necessary lines of code I don't really need to read to follow what's going on, I like to indent them more deeply just as a signal that those lines are extra-boring and can be ignored. I doubt Python would let me do that.

Reputedly, Lisp is so flexible that you can create your own languages in it, and redefine the Lisp language itself.

So, I wonder if it might actually be possible to make Lisp understand the remarkably English-like Inform 7 or HyperTalk?

Computers are some of the most powerful, useful tools ever created, and I think it's very regrettable that the unnecessary abstruseness of so many programming languages thwarts many intelligent people from doing much of anything with their computers.

People shouldn't have to be technical wizards to be able to put their computers to more use.

It's 2015, and by now there ought to be a really great successor to HyperCard (which was originally released in 1987, according to Wikipedia).

I recently found out that Paul Graham's book On Lisp is legally available for download from his website, for free:

On Lisp, by Paul Graham

Not just a sample, the entire book!!

I haven't read most of it yet, but I assume it will be a great book. I really like his nice, clear writing style, and even back when I was primarily a Windows XP user years ago, I found his articles on Lisp so intriguing that I downloaded Lisp in Windows.

Though back then, I quickly gave up, or just drifted away from it due to being so preoccupied with my PHP projects, and having no idea how to make Lisp do anything as interesting as what I could already do with PHP, or anything interesting at all.

But now that I have so much more programming experience, and switched to Linux (in 2011), and recently managed to customize my Emacs setup so nicely that it has become my favorite editor... hopefully now I have a better chance of being able to figure out Lisp.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
How to compile newLISP in Lucid Puppy Linux 5.2.8
Sunday, December 27th, 2015
14:58:21 GMT

Puppy Linux

Compiling newLISP 10.6.2 from scratch in Lucid Puppy Linux 5.2.8 wasn't as tough as compiling GNU Common Lisp 2.6.12, but it was still a bit tricky.

  1. You can download newLISP's source code from here:

  2. Then, download libffi from here (I used version 3.2.1):

    I don't know if most typical Linuxes usually already have that or not, but, Lucid Puppy 5.2.8 version 004 doesn't, and newLISP needs it.

  3. Unzip the libffi source code tarball, open the libffi source code folder, and open a terminal window. Then, do these 3 commands:

    make install

    (Or "new2dir make install" (without quotes) if you'd like to make a .pet or .sfs file.

  4. Next, unzip newLISP's source code, open the newLISP source code folder, open a terminal window, and type:


  5. Don't type "make" yet. For some reason, ./configure wrongly assumes libffi is at a location it's not at, so you have to open the file "makefile_build" in a text editor and fix the mistaken path in it.

    This is the line you need to change:

    CFLAGS = -fPIC -m32 -Wall -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE -DSUPPORT_UTF8 -DLINUX -DFFI -I/usr/local/lib/libffi-3.0.13/include

    And here's what you change it to:

    CFLAGS = -fPIC -m32 -Wall -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE -DSUPPORT_UTF8 -DLINUX -DFFI -I/usr/local/lib/libffi-3.2.1/include/

  6. Now, you can type "make" (without quotes), and the build should succeed now.

  7. Next, you can type "make install" or "new2dir make install" (without quotes) to install newLISP.

  8. And the last step is, you have to create a symlink so newLISP can find a shared library which newLISP mistakenly looks for in the wrong place.

    This command will create the symlink:

    ln -s /usr/local/lib/ /usr/lib/

Now, it should be possible to run newLISP just by typing "newlisp" (without quotes).

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
How to compile GNU Common Lisp 2.6.12 in Lucid Puppy Linux 5.2.8
Sunday, December 27th, 2015
14:39:57 GMT

Puppy Linux

I had a tough time compiling GNU Common Lisp 2.6.12 from scratch in Lucid Puppy Linux 5.2.8 version 004.

But, I finally managed to do it. Here's how:

  1. GNU Common Lisp can do things with Tcl/Tk, but only if you have Tcl/Tk installed.

    As far as I know, Lucid Puppy 5.2.8 doesn't include Tcl/Tk by default. So, if you want Tcl/Tk, you can download their source code here:

    I downloaded version 8.6.4 of both Tcl and Tk.

  2. Both Tcl and Tk were nice and easy to compile. I don't know if you have to compile and install them in a particular order, but I think I compiled and installed Tcl first.

    All I had to do was unzip each source code tarball, open the source code folder, open a terminal window, and put in these three commands:

    make install

    (Though I actually used the command "new2dir make install" (without quotes) because I wanted to make .pet and .sfs files.)

  3. GNU Common Lisp itself was far more troublesome to compile. You can download its source code here:

  4. Unzip the source code tarball. And if you want to make a .pet or .sfs file of make .pet and .sfs files, rename the gcl folder to "gcl-2.6.12" (or whichever version you're trying to compile).

  5. Next, open your gcl source code folder, then open the "h" folder. Then, open the "make-init.h" file in a text editor.

    Above the line which says "#include <signal.h>" (without quotes), add this line:

    #include <sys/ucontext.h>

    (Huge thanks to the author of this post for the solution, because without that post I would have had absolutely no clue at all what to do.)

    The above fix makes it so the compilation won't be stopped by these errors:

  6. Go back to the gcl source code folder, open a terminal, and type these three lines:

    ./configure --enable-tkconfig=/usr/local/lib/ --enable-tclconfig=/usr/local/lib/



  7. After the build is finished - if you want to make a .pet and/or .sfs file, type this:

    new2dir make install

    Or, if you'd rather just install it without building a .pet or .sfs file, type this:

    make install

  8. Just one last nuisance to deal with. The file /bin/gcl has to be moved or renamed, because otherwise, your system might mistakenly try to run that instead of the correct gcl file at: /usr/local/bin/gcl

After all those steps, it should be possible to run GNU Common Lisp simply by typing "gcl" (without quotes).

If you have Tcl/Tk, here's how you can try them out with GNU Common Lisp.

Go to the gcl source code folder, open a terminal prompt, and type:


Then, at the GCL prompt, put in these commands:


(load "gcl-tk/demos/widget.lisp")

That last command will fail if your current working directory isn't the gcl source code folder.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Emacs Add-On: multifiles-apmod.el
Tuesday, December 15th, 2015
21:12:56 GMT

Emacs Lisp

I finally managed to make most of the modifications and additions I wanted to make to Magnar Sveen's incredibly useful "multifiles.el" add-on for GNU Emacs.

Here's multifiles-apmod.el on GitHub:

(Addition, Jan. 10, 2016, 4:52 PM: Updated to Version 2.0, which partway fixes a really bad glitch I discovered today.)

Addition, 12/21/2015, 2:07 AM EST: Recently figured out and uploaded a slightly better solution to the slowness of my large PHP multifiles - perly-php-mode.el, which is simply perl-mode.el slightly modified to masquerade as php-mode. 12/24/2015, 5:24 AM EST: Released version 1.2.)

It's so nice finally being able to mindlessly scroll around my entire projects (at least the smaller projects) all in one page. I don't have to do searches nor even click tabs to get around.

Now, my difficulty remembering which files I put whatever things into won't get in my way as much anymore. If I space out and forget something, I can just daydreamily float around until something scrolls by which reminds me. Much more effortless and relaxing than having to click from tab to tab, or try to remember what I named things so I can do searches.

And searching is easier too, with everything apparently being in the same file.

Someday, I'd like to have an even more bizarre code editor with a concept map layout similar to VUE, or something like Code Bubbles (which I still haven't tried yet but which seems really cool, from what I've read/seen).

But, I think multifiles-apmod.el and GNU Emacs will already suffice to make it tremendously easier and more comfortable for me to get most any of my projects done.

Hopefully others will find it useful too. Perhaps even non-programmers might like it, such as anyone who likes Scrivener's Scrivenings mode.

So, I guess now I can finally return to working on my usual projects again.

I still haven't 100% perfected my Emacs setup, but, it's already mostly more comfortable for me to use than even my previous favorite editors, Notepad++ and Geany.

So, I think this might be the beginning of a golden age or renaissance for my programming hobby (or maybe almost career).

Tremendous thanks to everyone who made this possible!

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Links: Buffalo buffalo, etc.
Saturday, December 12th, 2015
18:31:41 GMT


Supposedly this is a grammatically correct English sentence:

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Amusing, though a bit hard to believe. But hey, it was in Wikipedia, the encyclopedia that can be edited by anyone, so it must be true. :-)

Even this video makes more sense. :-)

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Links: "Lion-Eating Poet in the Stone Den" poem
Wednesday, December 9th, 2015
18:43:41 GMT


About 20 minutes ago, I stumbled across this amusing poem in Chinese, written exclusively in characters pronounced "shi" (with different tones):

Lion-Eating Poet in the Stone Den

And here's a blog post I found with an in-depth analysis, at a blog called A Cup of Fine Tea:

“Shi and the Ten Stone Lions”: Riddle or Nonsense?

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑
Emacs Lisp code: Mouse-Clickable Search Results in Helm (with some glitches)
Friday, December 4th, 2015
14:24:50 GMT

Emacs Lisp

Helm is one of the most useful add-ons I've found for the GNU Emacs operating system - uh, I mean, text editor - so far.

Helm makes it tremendously easier to find all sorts of things such as files, buffers, function names, variable names, and text within files or buffers. In many Helm modes, you can just type a few letters, and Helm will narrow down your search and instantly display updated results.

Helm also gives you a way to browse and search your "imenu", which is where php-mode puts a list of functions defined in the PHP file (or multifile!) you're currently looking at.

And you can easily go to any of those functions by selecting its name in the Helm search results and pressing Return or Ctrl-j. Or, thanks to the below code, by double-clicking or right-clicking on any item in the Helm search results with your mouse.

By default, the Helm add-on has no mouse capabilities at all. So, I kept accidentally trying to click Helm results, resulting in nothing happening.

That seemed like the sort of thing someone probably already wrote an add-on to fix, so I searched the web, and soon found this post on Reddit:

Select helm candidate by using mouse (click)

To my delight, that code worked quite well out of the box. But, it globally overwrote my preferred mouse click settings, so, I had to figure out how to make some custom mouse click settings that would only be in effect while Helm was running.

Even though my final result wasn't very much code in the end, it still took me hours and lots of trial and error to figure out how to do it, and I wasn't sure I ever would figure it out. But somehow, I managed to cobble together the below code, which uses most of the code provided in the abovementioned Reddit post, plus some other code to create a custom minor mode which is supposed to only run when Helm is active.

Since I'm such an Emacs newbie, it would have taken quite a lot longer if I hadn't been able to stand on the shoulders of numerous giants, such as the author of the code in the abovementioned Reddit post, and all the authors of all the web pages and documentation I read that helped me figure out how to do this.

Thanks to everyone!

I still haven't figured out how to make the below code not get confused by mouse-wheel scrolling, and there could be other glitches too.

But, it still makes Emacs and Helm more cozy and intuitive to use.

I'm using GNU Emacs 24.5.1. And I'm not sure what version of the Helm add-on - all I know is I downloaded it on Nov. 13, 2015 at 6:22:26 AM EST from GitHub.

The below code only requires the Helm add-on, and can just be copied and pasted into your .emacs settings file, probably somewhere after the place in your settings code where you loaded Helm.

While trying to debug the above, I figured out that one glitch I had actually wasn't caused by the above.

I figured out that the Purpose add-on interferes with Helm by somehow making Helm open help text in the wrong window pane - usually Helm's own window pane - which accidentally kills Helm sessions. The only solution to that I found so far was to turn off the Purpose add-on.

Edit, 2:47/3:08 PM EST. Added some missing backslashes to the above code. And changed some wording.

By the way, I actually often make small, usually unmentioned edits to my blog posts after I publish them - but this edit seems important to point out because the lack of those backslashes probably could have stopped the code from working properly.

I guess the vanishing backslash problem is another thing I need to fix in my WordsPlatz blog software. WordsPlatz has served me well with scarcely any changes since 2009, but, I actually am still interested in updating it and improving it.

   ▲ Top  ▼ Bottom  △ TOC   ↓ Down   Up ↑

   ▲ Top  ▼ Bottom  △ TOC   Up ↑
Emacs Lisp code: Right-Click to Highlight and Select Name - Sort of Like Notepad++
Wednesday, December 2nd, 2015
06:47:22 GMT

Emacs Lisp

The text (and code) editor Notepad++ has a nice feature where all you have to do to temporarily highlight a name (such as a variable name, function name, command name, or other words) everywhere is double-click on it.

Emacs doesn't do that out of the box, and I didn't find a way to make Emacs behave exactly like Notepad++.

But, I like the below behavior more in some ways anyway.

I'm using GNU Emacs 24.5.1. The below requires three add-ons:

Here's all the code I had to add to my .emacs settings file:

Sorry, I don't know how to get rid of the "Wrong type argument: syntax-table-p, nil" error message. But it seems to work fine despite that error message.

And the above code does interfere with whatever right-clicking is supposed to do by default. But the original default behavior of right-click was rather dangerous and useless-seeming - unexpectedly selecting blocks of text and often deleting any text that was already selected - so I'm glad to be rid of that, whatever that was.

After adding the above code and add-ons to your Emacs, it should be possible to right-click on a name to highlight that name everywhere persistently.

The highlighting persists forever until you either right-click on the name again, or run the (highlight-symbol) function in some other way, such as clicking on the name and pressing F3 - the key I've bound to (highlight-symbol).

Right-clicking not only highlights the name, but also selects (or "marks", in Emacs jargon) some, most, or all of the name under your cursor (or "point", in Emacs jargon).

If you right-clicked on a dash or underscore in the name, the entire (or almost entire) name gets selected. Excluding any dollar signs at the beginning, to make it easier to select the names of PHP variables without their $ prefix. (But if you ever actually want to also select the dollar sign, a normal left double-click on a PHP variable name, or an underscore inside it, should accomplish that.)

If you right-clicked anything other than a dash or underscore, the only thing that gets selected is the word you clicked. So, you can easily select individual words in a function or variable name with dashes or underscores in it - something I never figured out how to do in Notepad++.

However, in Emacs, I don't know how to make it possible to so easily persistently highlight (as opposed to select) just individual words, because highlight-symbol.el pays no attention to what text you have or haven't selected - it just highlights the entire name it detects where your cursor (point) is.

But, doing a search while using the code from this previous blog post - Emacs Lisp code: Easily Search for Text You've Selected - will let you easily and case-insensitively put a temporary highlight on any arbitrary currently-selected text.

   ▲ Top  ▼ Bottom  △ TOC   Up ↑