An Applet a Day Keeps the Doctor Away

I'm subscribed to the Debian PPC mailing list (if you aren't yet, you definitely should be!) and recently read about a "new" Gnome (both a gtk2 and 3 version) battery menu applet for our PowerPC portables as well as a version of it that was ported to C.

You can read more about the applet here and the C code can be downloaded from Github here.  The version written in C is actually relatively straightforward code to read through. As another user mentioned, it is kind of cool to see how a menu applet can actually be written and works.

Once you've downloaded the zip file, unpack it by running the following command inside the folder where you downloaded the zip, such as your user profile's Downloads folder.

unzip mac-battery-applet-master-master.zip

Change directories into the unzipped folder and run:
make install

This should copy the Linux PPC executable to your /usr/local/bin folder so go ahead and type mac- and it should auto-complete the command to mac-battery-applet for you. Hit enter and you should see a small battery icon appear in your task bar/panel as can be seen from the screen shot below.

Hovering your mouse over the icon brings up a small pop-up of sorts that gives you the remaining estimated battery capacity and number of minutes of runtime until the battery is depleted.

Of course, you don't want to manually run this every time you reboot or power on your PPC laptop, so go ahead and add it to the necessary startup configuration for your desktop environment.  For LXDE, I added the line @mac-battery-applet to my autostart file located at /etc/xdg/lxsession/LXDE.

There are numerous battery icon files for showing the percentages of remaining capacity and they exist for both when the laptop is on battery power and when it is charging.  When the laptop is plugged in and charging a small + symbol appears on the upper right hand side.  A function called build_icon_file_name creates the necessary filename and it uses the code in files.c to construct the path for the corresponding file for that % of battery based on the built filename.   There is a lot more to it all, but pretty cool I think overall.  Some might prefer to have more granular results, but I think the 10% increment icons are an okay trade-off.  Ideally, I might do 5% increments, but that could become quite tedious when creating the icon files.  

Reading through the README, it says there is currently no Debian package for this applet, but the author states he would be more than willing to let someone else tackle that project. I've personally never done this, but perhaps it would be worth it to finally use it as a chance to learn all that does go into building a Debian package if it is even that much?  I've heard arguments on both sides.

Anyways, there is much more valuable information in the links I provided, including possible future updates to the applet, such as custom icon themes, so I encourage you to check those out. Did I mention this was done on a recently purchased 1.42 GHz G4 iBook? Yeah, I am stoked. I'm almost done with the memory upgrade and tests on the G4 QS.  Look for it in the next couple of days.

Thoughts on the Filesystem's Future

If you don't mind too much, I'd like to sort of run astray from my usual PPC related content here and discuss my thoughts about the future of the filesystem.  Roughly 99% of it is entirely my opinion so take everything with what some call a "grain of salt."

I've recently read a couple of articles about the subject of the filesystem that covers arguments about both its impending doom and its forever omnipotence in computing devices. Since then I've wanted to add in my own thoughts on the matter. For some reason, I am currently unable to access the article I am referring to, but will check back periodically to try and post a link. The articles are not so much discussing the actual end of files and the filesystem, but the idea of its access being stripped or abstracted away from a typical user.  Much of what you'll read below covers both such scenarios, so hopefully it's as clear as mud.

You could say the topic is still somewhat related to my blog content as of course our PPC system's are computing devices and would likely be affected by any changes that may or may not happen to the filesystem going forward. I'd like to argue that the filesystem is a construct which is here to stay for a very considerable part of the foreseeable future. 

Let me provide a few of my arguments that will support my earlier outlined stance on the topic. Personally, I believe, overall, the filesystem has a long life ahead of it as it is currently such an integral part of a typical computing device whether that be a desktop, mobile phone, wearable devices... the list could go on and on.

Many define the filesystem as the construct allowing the control of the storage and retrieval of data, which is true, but its so much more than that. Some would also state, the filesystem is a lower level construct, probably even more so these days with mobile device operating systems (Android, iOS), which have abstracted away the idea of files and file organization in one sense, but more on that later.  Regardless of whether an end user knows it or not, the filesystem is an important piece in the operation of the device in so many different ways. 

Now I'm well aware that so much more is happening between the thin layer that is the filesystem and the actual hardware, but it is a good portion of the glue mixture that brings everything together in the end to make the device useful. I might even go so far as to say it is the very foundation and fabric of any virtual existence.

I often create analogies of computer related concepts of which correlate to that of the human body or a vehicle as it often helps paint a more clear picture for myself and others of what the subject's function is and how it works. So bare with me here. Files are to the computing system as DNA is to the human body.  They contain a lot of the logical computational makeup (not the physical makeup obviously) of the device helping to shape what it does and again how it works. The analogy isn't a perfect fit, but I think it does the job well. Basically, just know files are incredibly crucial at this point to the operations of a device.

My second argument is that the filesystem itself is still rapidly evolving to this very day.  Think of the numerous types of filesystems in existence such as FAT32, OS X Extended (and extended journaled), NTFS, EXT4, ZFS, CIFS, etc and the differences and similarities between each. Some have been around for ages, but there are always newer versions or replacements being introduced that build on or improve the ideas of those that came before it.  Overall, there are still many weaknesses to be resolved and strengths to be improved upon. I could write on and on about the complexities of such filesystems and what they are or are not capable of or what could be done to improve them.

Unfortunately, a lot of the knowledge and understanding of files and the filesystem has always been an incredibly difficult one for non-technical individuals to comprehend and make use of, so a lot of them could care less about its existence. Hence the reason for it slowly but surely being phased out on some platforms. To them the filesystem is another layer of complexity they would rather NOT have to care about in the first place. All these end users want to know is that their files are 1) there (and by "there" I mean  on the desktop usually),  2) safe, and 3) (for some more tech-savvy) secure.

As a network administrator ("IT guy") it is a bit frustrating trying to teach others to grasp such a concept as for me it is incredibly straightforward, simple, and analogous to the real physical things in the physical world.  I'm sure all of us have heard of the idea of thinking of the filesystem as being quite similar to an actual filing cabinet. So one part of me is partially glad that its disappearing as it is less overhead for me when working with end users, but at the same time, I do not want to lose the vast amount of power that comes with having unlimited access to the filesystem.  Then again, will it be less overheard for somebody who does IT work/development or will it actually increase?  Either way, I believe its going to further devolve the computer abilities of the masses in many ways and likely decrease the already thin patience of an end user when something does go wrong in relation to their files.

Let me be very clear and state that I'm not in any way against the possibility something could eventually replace the filesystem as in time all things must live and die.  As all tech-savvy people know, this is most definitely true in the technology world and is so at a much more rapid pace than many other areas in life. The difficult part is trying to imagine or conjure up any sort of idea of what would take its place as the application and use of the filesystem has been strongly cemented into my understanding of computational devices and how they work.  As a coder or developer, I would feel even more strongly of this as everything I code comes together across multiple files both of my own and of the system I write code on to create a lot of the "magic" we take for granted today. I'm being incredibly vague, but again I'm trying to paint a clear picture here.

Part of me wonders if somehow the idea or even the files themselves will be somehow virtualized in some sense beyond that of which they currently are and can be today.  I'm talking at a much lower level than of which is available to us today through actual files (of course they are not physical) and virtual hard disks using technologies such as VMware, XenApp, Linux KVM, or Hyper-V. Beyond that, my mind simply draws a dark empty blank void of which nothing can fill.

My guess is that you (the reader) have much different thoughts and opinions on the matter and I would absolutely love to hear each of them.  So please do share! Anyways, back to regular content after this, but I hope you enjoyed the small change of password and perhaps thought provoking content.