| 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.
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.
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.
▲ Top ▼ Bottom △ TOC ↓ Down Up ↑
| Pale Moon - a faster, more stable web browser than Firefox |
|
Tuesday, January 12th, 2016 06:20:36 GMT |
| Software |
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.
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.
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.
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.
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.
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.
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.
▲ Top ▼ Bottom △ TOC ↓ Down Up ↑
| Closed Source, Proprietary Food Products Are Bad Too |
|
Tuesday, January 19th, 2016 12:16:44 GMT |
| Health |
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.
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.
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.
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.
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.
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.
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.)
Anyway, this all would be less of a problem if the recipes of these products weren't probably secret and proprietary.
Another problem with the "closed source" food industry is vague, uninformative ingredient names such as "natural flavors" and "artificial flavors".
▲ Top ▼ Bottom △ TOC ↓ Down Up ↑
| Link: Free Software Foundation (FSF) Vision Survey |
|
Wednesday, January 20th, 2016 00:29:29 GMT |
| Activism |
The Free Software Foundation (FSF) is doing a survey until the end of January 2016:
And here's the FSF.org 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: My replies to the Free Software Foundation (FSF) Vision Survey |
|
Monday, February 1st, 2016 06:13:30 GMT |
| Activism |
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.
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.
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.
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.
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.
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. :-)
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'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.
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.
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.)
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 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.
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.
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.
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.
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.
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.)
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.
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.
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:
...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.
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.
I'm also very happy that Puppy Linux is also systemd-free and will hopefully stay that way.
(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.)
And the VUE concept mapping software also continues to help me:
Sometimes I think things like news articles could benefit from being in a VUE-like concept-map format.
For a long time I've wished I could edit actual code itself (rather than just notes about code) using VUE.
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.
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 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.
Emacs, multifiles-apmod, other Emacs add-ons, and VUE have been helping me renovate my Puppy Linux Setup Kit:
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.
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.
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.
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.
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.
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.
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).
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.
I'd also like to make it possible to write Puppy Setup Kit scripts in any language, not just Bash or Perl.
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:
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.
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:
Recently, I was very pleased to hear about the $5 version of the Raspberry Pi.
And, after all the distressing things I read about systemd, I was very happy to hear about the Devuan project:
(The rest of my survey replies will be in future blog posts.)