Open potential

There is a lot of debate going on about the closed vs open nature of the iPhone and Android platforms for the phone.  Those debates tend to be limited to mobile devices.  If you plan on only using iOS on your mobile device, there are a lot of advantages to the closed platform.  What happens when you want to use iOS on something else?  How about a TV?  You can answer with "Apple TV", but that is more of an example of why closed platforms are bad.  They limit the potential of the platform.

In a closed platform, you have to wait for the vendor to move the platform to a different device.  You can't try to install it yourself.  The vendor has complete control.  For iOS, Apple released Apple TV, but it didn't go over very well.  Although Apple TV uses iOS, it doesn't have the look and feel of the mobile version.  The mobile market isn't available on Apple TV.  Since iOS is a closed platform, you can't try to install iOS onto a mini-pc that hooks up to the TV.  You are limited to what the vendor says you are allowed to do.

For open platforms, you don't have to wait for the vendor.  There are mini pc's available that come preloaded with Android.  There are also mini pc's that you can install Android onto.  These devices have the full market on them.  If a new competitor to Hulu or Netflix comes out, and they release an Android app, then you already have support for it on your mini-pc.  You don't have to wait for an OS update.  None of this work was done by Google, however.  Since Android is an open platform, hackers have been able to modify the source code to run on the mini-pc's.  Android TV's have a long road ahead before they become really useful to the non-techie, but they are getting there.

Its this open nature that promotes the platform as a whole.  You don't have to wait for Google to make decisions.  You don't have to ask for Google's permission.  You don't have to put in a support ticket to figure out how a piece of the operating system works.  You can just try it and see what works.  From here, the vendor can learn from the hackers (and maybe even hire them).  When they try to make the official version, they can do it faster and avoid many mistakes the community made.  This is what a real community looks like.

Writing a closed platform like Blackberry takes a short term thinker.  You get a functional phone but that is about it.  Writing a closed platform like iOS takes a medium term thinker.  You get a great platform that makes for one of the best for phones available.  That platform even extends to tablets, which are essentially large phones.  Writing an open platform like Android requires a true long term thinker, however.  You see the mobile space that iOS is trying to capture but you also look a the potential for other devices that are not similar to mobile devices.  You look beyond the phone, into the unknown.  A true long term thinker wonders how something can be used for a completely different purpose.  Hackers are already building Android TV computers.  People already install Android onto laptops.  Imagine having Android installed onto a HUD in your car.  Imagine Android on your house thermostat.

I miss Yoshi

I have started to watch the New Super Mario Brothers Wii episodes of Hank Games, so my wife and I started playing the game again.  We picked up where we left off the last time we went on a Mario Brothers kick.  I love the New Super Mario Brothers series because it returns Mario to some of the roots that made the series great.  The one thing I miss is Yoshi, though.  Super Mario World was a great game and part of what made it great was Yoshi.  Although only a fraction of the levels had a Yoshi in it, you could bring your Yoshi's with you after you complete the level.  Also, the secret level that gives you a Yoshi and a cape was awesome!  The is the only feature that I dislike about New Suprt Mario Brothers Wii.  You can't use Yoshi on most of the levels.  Now, whenever you get a Yoshi, you get really upset when you lose him, because you know it will be a while before you can get another Yoshi.

The importance of regular backups

I previously discussed my love of virtual disk snapshots.  This is a story of how snapshots can go wrong.  I recently found some free Windows 95 programs hosted on a Microsoft ftp server.  Some of the software were demo's but some were the full versions of some old school software that I wasted a lot of my youth on.  Naturally, I wanted to install some of these games.  Before installing new software into my Windows VM, I like to take a snapshot, just because I can.  Actually, its because some software can be detrimental to the operating system, so I want a way to uninstall that software without the uninstaller leaving behind dll's that slow my VM down.

I shut down my VM, then start taking a snapshot.  All of a sudden, the qemu-img program crashed with a Segmentation Fault.  I tried booting my VM and it wouldn't boot.  It claimed the disk was invalid.  I decided to apply my previous snapshot (from a week earlier) but the VM still wouldn't boot.  Luckily, I do perform other types of backups.  Since the VM disk is just a file on the filesystem, I have been copying the entire file onto another hard disk.  Creating a snapshot backup uses almost no hard disk space, due to the nature of the copy-on-write design of the file format.  Copying an entire virtual disk uses a lot of disk space.  Therefore, I didn't use this form of backup as frequently.  My previous backup using the disk copy was two months ago.  So, due to a Segmentation Fault, I lost two months of progress on Angry Birds!

Now, I have set up a weekly cron job that shuts down all my VMs, makes a complete copy of the virtual disk, then makes a snapshot.  If the snapshot fails, it copies the new backup of the virtual disk back.  It finally starts the Windows VM back up again (so my wife can always play Angry Birds whenever she wants).

The 20ft Interface

There are many programs out there that claim to have a 10ft interface.  A 10ft interface is supposed to be an interface that is usable up to 10ft away.  The problem with almost all 10ft interfaces, is that they aren't usable at 10ft.  There are really only usable up to 5ft.  At 10ft, you have to squint.  The text is so small that the interface really isn't usable.  This happens because the developers of the software had to fix so much content on the screen but it wouldn't all fix.  They ended up shrinking the text and content so that it would all fit in the screen.  This layout is still easier to use at a distance than a standard desktop pc layout, but is still pretty hard to use.  Therefore, I define a 10ft interface as an interface that is usable up to 5ft away.  Most DVR and HTPC/Media Center PC setups fall into this category.  This includes TiVo, Comcast DVR, FiOS DVR, MythTV, XBMC and Windows Media Center Edition.

One of the reasons I created my own HTPC software was because of the unusability of the 10ft interface.  I decided to create what I call a 20ft interface.  A 20ft interface is an interface that is usable up to 10ft away.  20ft interfaces have some advantages and disadvantages over the 10ft interface.  First, the 20ft interface doesn't require you to squint.  All the text is readable.  Choosing a movie or a tv show is very easy because you can clearly identify every title on the screen.  Also, the movie or show descriptions are readable.  So, if you are looking for a particular episode, you can do that without heading a headache.  The problem with the large text size is the fact that large bodies of text won't fit on the screen.  It is usually easy to edit movie and show descriptions to be smaller.  What is really hard is handling movie and show titles that are really long.  They tend to get clipped of screen.  I did make changes to the software to automatically shrink the text for long titles to a limit, but there is a lower size threshold.  This allows you to easily read most titles, but strain a little bit on the longer titles.  Below are screenshots of my FiOS box and my HTPC software:

Another disadvantage of the 20ft interface is the lack of eye candy.  You only have so much screen real estate.  When you make text really large, most of the screen is used for text.  This doesn't leave room for album covers or movie posters.  With a 20ft interface, you mostly only see text.  Some text is highlighted, and you move up/down to navigate.  This interface style isn't as nice as XBMC, but it does have the advantage of speed.

Without the eye candy, all you are rendering is text.  Text is easy to render.  This means the CPU and memory requirements for a 20ft interface are actually less than a 10ft interface with eye candy.  Many set top boxes are loaded with eye candy.  There are various images and icons inside of the menu system.  There are various widgets that run.  There is a lot of content.  That content contributes to the slow speed and the difficult nature to use from 10ft away.  It is a very hard leap to write functional interfaces that work at distances of 10ft or more.  The current TV developers can't learn from me because my interface cheats to a certain degree.  My HTPC actually has two interfaces.  The 20ft TV interface is used to select what you want to watch.  That is it.  You can't do anything else.  You can't configure it.  You can't schedule anything.  It is just for selecting what you want to watch.  The second interface is an integrated website.  All configuration is done in that website.  Set top box developers have to put their entire interface on the TV, while I don't.

There is a new generation of developers that are handling these problems today, they just don't know it yet.  Because of the strides they are making, and the designs that they are creating, I'm actually ditching my 20 FOOT interface for a 10 INCH interface.  That's right.  I'm building an Android TV!

Maven repository retirement

What is the best strategy for retiring an artifact out of a maven repository?  You can base it off of time; you only keep 2 years of milestones and latest snapshots.  You can check based on how long since the last time an artifact has been accessed.  It is probably a good idea to keep every artifact around that is currently in production, just in case you need to fix something.  You also have to figure out how many versions of a snapshot to keep.

I would like to see garbage collection as a method for artifact retirement.  Let's start by defining the roots as everything that is currently used by production, qa and development.  We can also add implicit roots for every artifact that is younger than a set period of time.

From there, we can you a standard mark-and-sweep algorithm that starts from the roots and goes through all of there dependencies.  Anything that isn't marked gets deleted.  If you use the symbolic link concept for milestones then this answers the question of how many versions of a snapshot to keep.  Garbage collection will take care of removing all the snapshots that are too old but not in use.  Garbage collection has an added benefit of indexing the reverse dependencies.  The collector can save the path to the root when it marks an artifact.  This helps you answer the question "who is using this artifact?"

Private clouds are a matter of scale

I came across an article about some new technology coming out of Oracle related to cloud computing.  Although I'm not a fan of Oracle's cloud technology, I don't agree that the technology doesn't qualify as being a cloud.  While reading the article, I was surprised to read that private clouds are not even real clouds!  The author refers to private clouds as a way of managing resources in a cloud-like way, but are not clouds.  I completely disagree with that.  Why isn't a private cloud a "true cloud"?  The author defines a cloud as "...improving use and cutting costs by giving buyers as-needed access to a portion of a much larger pool of shared resources".   To me, private clouds still fall under this definition.  Why does the larger pool of shared resources have to belong to a different company?  Why does that company have to sell those resources to another company?

Some large companies have multiple divisions.  One central IT division can create a "large pool of shared resources" and "sell" those services to the other divisions.  If one division has a sudden need for more resources, the central IT division can decrease the resources for one division and increase the resources for another division.  To me, that is the key to cloud computing.  With cloud computing, the subset of resources that a "unit" is using should be elastic.  If you require a 20% increase in resources, you should be able to increase your capacity in a relatively low amount of time.  That "unit" using the resources does not have to be a different company.  They just have to be able to get resources if they need them.  This private cloud example matches what Amazon does, but Amazon does it in a much larger scale; selling resources to other companies.  A private cloud is still a cloud, but instead of one massive company selling resources to a lot of small companies, you have one division selling resources to a few other divisions in the same company.

Given the definition that the author gives, Oracle's offering could be a "true cloud".  The author says that a company buying a fixed pool of resources makes a mockery of cloud computing.  I think ignoring the size of a company makes a mockery of how business works.

Android RSS Readers

I have been trying to find an RSS reader for Android and I wasn't having any luck.  Like most technology, each person uses it in a different way.  I want to use rss feeds so that I can be notified about updates to websites or software that I like.  I don't want these websites to email me about updates, but I do want notifications.  In another article, I will be talking about the need for an open protocol to fill this gap, but for now, I will be using rss feeds.  For this purpose, the main thing I want is for my phone and tablet (and soon my Android TV!) to post a notification when a website has made a change.  Some webpages don't update very frequently and when I'm waiting for the latest version of some piece of software, I don't want to check the site over and over again.  Other notifications include new Youtube videos being posted.  The idea (the original idea with rss) is that I don't have to check anywhere.  I just get notified of changes.  I can then read it right away, or later if I'm too busy.

The obvious choice was to start with Google Reader.  I started getting frustrated with it pretty fast.  I was having issues with the update interval with Google Reader.  Google refused to let me force a refresh of my rss feeds.  Unfortunately, most Android rss readers are not actually rss readers.  They are 3rd party Google Reader apps.  This means they don't actually download the rss feed.  They use a Google api to list the available news articles.  This isn't unreasonable, since Google can download the feeds while the app just asks Google "is there something new?"  This reduces mobile bandwidth which is a good thing.  When Google Reader isn't giving me real time updates, though, this means this entire class of Android app are useless to me.

The next class of rss readers are the news readers.  These apps support rss feeds but their main goal is for you to read the news inside of the app.  They spend most of their time making the app user friendly and have lots of eye candy.  If I was going to spend a lot of my time in an app, I would want it to be user friendly.  This isn't what I want in a reader, however.  These apps tend to be overkill, and you end up paying for it in battery and data in the long run.  Since these apps are intended for you to read your news articles inside of them, they pre-download all of your news articles.  This includes images and other content.  Pre-downloading allows you to view your news offline.  This is handy for the subway commuter who wants to read news on their commute too and from work, but not for a notification system.

I finally found a true rss reader: RssDemon.  This was a nice tool, but it had problems reading some of my feeds.  Those feeds would come up with zero news articles available.  I don't know if it was a parse error or what.  It just didn't support some of the feeds I wanted to monitor.  Finally I found Sparse rss.  The name alludes to the fact that there isn't many features in this app.  It reads feeds and notifies you when there is a new item.  The widget wasn't that great.  It was hard to tell where one item stopped and the next started.  I haven't figured out how to scroll through the entries.  When adding the widget, a config screen opened up.  I don't how to get back to that config screen after adding the widget.  As a stop gap, I can remove then re-add the widget to access the config again.

Overall, Sparse rss is good enough for now.  It allows me to get notifications for rss items, which is the most important thing for me.