Site Update Blog Post:

Astroblahhh Desktop v2.3
9/20/2015

Post Below
9/20/2015 - Astroblahhh Desktop v2.3 (Site Update - Software Release)

    Hide/Show:


   ▲ Top  ▼ Bottom  △ TOC
Astroblahhh Desktop v2.3
Sunday, September 20th, 2015
20:36:25 GMT

Site Update
Software Release

This is a relatively minor update of Astroblahhh Desktop compared to what I'm working on.

Astroblahhh Desktop 2.3 (498 KB zip file)

(Addition, 6:55 PM EDT: Reuploaded because I forgot to include the GNU Affero General Public License.)

And, I should point out that like all the previous releases, I still haven't gone to as much trouble as I should to try to make it easy for people other than myself to install and use. And it still contains a ton of legacy code I wrote years ago, which has many bad design issues you'd expect from a relatively inexperienced programmer, such as using global variables all over the place. (Hopefully most future versions will be better in these regards.)


Despite all the organizer software I write, I'm still a lot more disorganized than I should be, so, I didn't keep very careful track of what I added to Astroblahhh Desktop since the previous release.

But, the most notable thing I recall adding is the ability for the file organizer to calculate SHA-512 checksums (also known as SHA-512 hashes) of files, and store them in file databases. Plus other things related to SHA-512 checksums, to compare checksums in two different databases, search for checksums, etc.

I did this simply so I could be more certain that my backup files in various disks (or discs) are intact. (Also, it's nice to be able to easily locate and group together identical files.)


This was inspired by a scary article I read which mentioned the concept of bitrot. Here is that article, from Ars Technica:

Bitrot and atomic COWs: Inside "next-gen" filesystems
"We look at the amazing features in ZFS and btrfs - and why you need them"


I was quite dismayed by that article, but didn't feel up to figuring out how to implement bitrot countermeasures such as switching to the ZFS or btrfs filesystem, or setting up some kind of automated RAID backups involving multiple hard disks.

But, that article made me realize (or reminded me) that I had hardly any idea how much bitrot my files might already be suffering. So, several months ago, I decided to temporarily set aside my work on Astroblahhh Desktop 3.0 (and other things), and solve this problem first. I think I finished this stuff back in June or July.

That article mentions checksumming a lot, so, that gave me the idea to add the new checksum features to Astroblahhh Desktop. Which aren't the same as the checksum features mentioned in that article - instead of calculating checksums for "blocks", Astroblahhh Desktop calculates checksums for the entire files.

Prior to this, I never did much of anything with checksums until I made the downloader script portion of my Puppy Linux Setup Kit, since I needed a quick and easy way to verify that downloads had been successful.

I wish I had paid attention to the concept of checksums much sooner, since it seems very clever and useful (even though of course I don't fully understand it).


After (and even while) building the SHA-512 checksum features into Astroblahhh Desktop, I went through my old file archives and made SHA-512 checksums for most everything.

A quite slow process, since I have a lot of files - and after a major reorganization of my disks a while back, I hadn't resynced my databases with the new actual locations of all my files yet, so that slowed me down too. (For the resyncing, I had to use Astroblahhh Desktop's "mass locate" and "mirrorer" features a lot, which made it quite a lot easier, but it was still not as convenient and automated as would be ideal.)

Another thing that made calculating checksums slower was, I made a way to make SHA-512 checksums for what I call "paired" folders - which are folders which often get created to hold the images, CSS files, etc. of web page files you save with Firefox and other browsers.

(I save a lot of web page files, so, even from the beginning of the file organizer portion of the Astroblahhh Desktop project, I went out a lot out of my way to build in capabilities specifically to deal with web files and their paired folders, so it wouldn't be as easy to accidentally separate web files from their paired folders.)


If I recall correctly what my paired folder SHA-512 checksum-making code does - all the files contained in the paired folder are checksummed, with each of their checksums added to a single long string, then a single SHA-512 checksum is calculated for that long string of checksums, and that gets used as the paired folder's checksum.

This is quite possibly stupid in some way I haven't yet thought of. (If so, I'd love to hear about it, or any other feedback. Comments are welcome at Eryss.Com Forum or can be sent privately to me.)

But, it seems to achieve the goal of reliably creating the same checksum for different copies of the same paired folder - so, I'm happy enough with it for now, even though calculating the checksums of paired folders is often much slower than calculating checksums for lone files.


So, now, if bitrot ever occurs, at least I'll hopefully be able to detect it at some point in the future. And, amongst all my many redundant backup files, I'll be able to tell which backups are intact and which are corrupted.

One of my new scripts enables me to compare the SHA-512 checksums in two different databases, so, after the slow chore of adding checksums to my databases, I was able to quickly and easily verify that my various redundant backups have all the same checksums in them. Happily, I haven't detected any bitrot so far.

It's so nice to be able to know with far more certainty that my files are intact, rather than just making lots of redundant backups and mostly just hoping they're all truly identical. (I did sometimes use the "diff" command on them, though.)


This might turn out to be one of the last, uh, conventional versions of Astroblahhh Desktop. (Though a web app that isn't intended to run on a web server on the internet isn't all that common/conventional. But, that's what Astroblahhh Desktop always was. So, this version is at least typical/conventional in the context of Astroblahhh Desktop's own history.)

Most future versions will hopefully have the ability to run as either a PHP-GTK true desktop app or a web app, and maybe even also a console/command line app.

Also, since I was able to get PHP-GTK to work with PHP 5.6.13, there's nothing holding me back anymore from starting to use whatever fancy new PHP features I was missing out on as a result of sticking with PHP 5.2.17 for so long.

I hope in the end, Astroblahhh Desktop will be easily installable, useable and useful even in Windows and MacOS, as well as Linux. (Well, it already is mostly tailored to Windows, since it was first written while I was still mostly a Windows user, and, up until now, I usually used it in a Windows XP VirtualBox, even though in 2011 I added some compatibility with Linux.)


Despite my recently-discovered adoration of graph databases, I still want to preserve Astroblahhh Desktop's ability to use MySQL/MariaDB and SQLite databases. (SQLite is currently useable in a not-yet-released version of Astroblahhh Desktop.)

They're still useful, even if they're not as mindblowingly flexible as OrientDB is, and even if I'm itching to build an OrientDB-based possible successor to Astroblahhh Desktop.

Astroblahhh Desktop's existing databases are also a lot less mind-boggling to me than my graph database-related daydreams.

But probably what's making the graph database stuff a lot more mind-boggling than graph databases normally are is my obsessive struggling with trying to design my ideal database software, with temporal-database fanciness, rewindable history, provenance of data instead of just data alone, multiple users, etc., etc. I haven't even started coding it yet, I've just been jotting down tons of notes and ideas in VUE concept maps and NoteCases.

All my lofty ideas seem a lot more feasible with a graph database rather than MySQL/MariaDB or SQLite. But, those ideas might be so difficult I'll have to give up in the end, and do something easier.

Fortunately, even something easier will probably still be quite powerful and useful, and quite possibly better than Astroblahhh Desktop with less effort.

Anyway, I've only struggled with designing my ideal graph database since late August, and only quite recently got PhpOrient to work (because I had to go to the trouble to update Astroblahhh GLMP-GTK to 2.0), so I'm not tired of the struggle yet.


Donations are microdonations are welcome. Meanwhile, goods and services still aren't really available yet. But services might become more available if/when I finally solve the various nuisances with my email.

I'm kind of fed up with the Thunderbird email client's overly bloated profiles and how complicated it is to deal with my email on multiple computers, since I usually prefer downloading my mail with POP3 rather than leaving it on the server using IMAP, and I don't want to have to mess around with figuring out how to merge different Thunderbird profiles from different computers together.

And I also want to escape Gmail, since it's closed source and a Service-as-a-Software-Substitute - SaaSS.


So, I'm seriously thinking about adding an email organizer to Astroblahhh Desktop and writing my own email-downloading software.

I somehow managed to compile PHP's IMAP extension (which, among other things, also can handle POP3 and even NNTP, the Usenet protocol). And then managed to figure out how to access one of my DreamHost email accounts with a PHP console script on my own computer (rather than uploaded to DreamHost).

So, my daydream of writing my own email software is starting to seem truly feasible. It may seem silly to reinvent such a wheel, rather than just look harder for existing email software that I like more than Thunderbird - but for some reason I feel inspired to go to the trouble.


I also managed to compile and use PHP-SWEPH 1.80 with PHP 5.6.13 in Astroblahhh GLMP-GTK 2.0. Just thought I'd point out that it's possible.

That also makes possible an up-to-date PHP 5.6.13+PHP-GTK edition of the astrology software Eryss - though I'm probably not very likely to work on that in the very near future, because astrology software is nowhere near as useful on a practical level as my other projects.


I haven't released any compiled Astroblahhh GLMP-GTK 2.0 binaries, and maybe won't at all, because I think it might be better to release Astroblahhh GLMP-GTK 2.0 as build-from-scratch scripts in another update of my Puppy Linux Setup Kit.

But, I haven't yet written the build-from-scratch scripts. I'll most likely get around to it when I get around to going back to Lighthouse 64 Puppy Linux 6.02 Beta 2, since I haven't built Astroblahhh GLMP-GTK 2.0 for LH64 yet.


Again, donations and microdonations are welcome.

   ▲ Top  ▼ Bottom  △ TOC


    Hide/Show: