The morning is a fertile ground for colliding thoughts. You're still groggy from sleep, and your mind isn't focused enough yet to drown out the noise it usually generates. Often, this state drifts me into the absurd. Laughter can usually be heard from the house bathroom as the bizarre thought collision reaches its zenith while I shower. 

This morning, however, I found myself thinking about two things that are rarely considered together: Tablet computing, and Haiku OS. While Tablet computing needs little introduction, Haiku certainly does. Haiku is an open source reimplementation of a then-revolutionary operating system called BeOS. Be aimed to be the multimedia OS of tomorrow through a radical new API based on C++, pervasive multithreading, and build-in media abilities. Originally available on PowerPC Macintosh hardware, and then garden-variety x86, Be was a weird, beautiful, and fast creature to behold.

Back in late high school and early college, I was quite fond of BeOS. I presented BeOS to room full of my college peers, showing off its ability to play four video streams concurrently on mediocre hardware. I wrote software for BeOS when not completing college assignments. For almost two years, it was my primary operating system. Eventually, however, reality caught up with the dream. Be Inc., the company behind BeOS made some very poor decisions, eventually needing to sell itself to then-powerhouse Palm, Inc. for a paltry stock price. The same day that was announced, I switched to Linux.

Haiku was one of two reimplementation efforts. One was called Blue Eyeed OS, aiming at source-level compatibility with BeOS. The other was the more ambitious OpenBeOS, now Haiku, which aimed at binary compatibility. At the time, I sided with the former, having already done some coding work toward that end myself. Eventually, however, Haiku proved the winner, and now the only surviving OS from that branch. 

So where do Tablets come in?

One of the attributes of BeOS was that it was impossible to theme. This was due to all the UI elements being drawn by hard code. No images or variables were used to control it's presentation. It's object oriented nature meant there was no single memory location in which this UI code lived. It was all over the place. At the time, this was just a hindrance to modders and power-users who wanted to control how their OS looked. Tablets, however, change the equation.

Tablets have a very different interaction style compared to the desktop computer of yore. Instead of pixel-precise pointing devices that scale down clumsy human movements to manageable computer increments, we use one to ten bony meat tubes to interact with the device. The accuracy of fingers leaves something to be desired. On major smartphone and tablet computer operating systems today, the hit-surfaces with which we interact with the device are comparatively large to their mouse-centric brethren. As tablets seem to be the popular computing form-factor going forward, how can an OS like Haiku hope to survive? 

"So," you might say, "just make the hit-surfaces in Haiku bigger, that should do it." Not so fast, you're forgetting about a lot of issues. A bigger hit-surface a tablet OS does not make. You need to reconsider every fundamental UI component. Do you even need windows? Does the Tracker (the BeOS equivalent of Window's task bar) even have a purpose? And those are just superficial issues.

Tablets are not desktops in very fundamental ways. The primary power source is battery, not AC. While performance is important, it must be quickly discarded in order to save on power. The preferred CPUs have a different architecture. You cannot even rely on a physical keyboard! If these were the only worries for Haiku in the tablet age, they would already be facing a formidable challenge. Haiku also inherits the OS architecture of the early 2000s. A time when hardware accelerated graphics were uncommon and the phrase "compositing window manager" had not been heard outside of research institutions and the dens of particularly forward thinking hackers. 

One might think Haiku can be easily reinvented for the tablet age. After all, we have the source code, why not just take on each of these challenges one by one? That's an admirable attitude, but if you only have a handful of developers and that attitude on one side of the scale, and all these issues on the other, you may find your elevation most displeasing.

Let's take these on one by one:

• UI. Okay, so yeah, you can modify the source code to fix this. The problem is that it's everywhere. You need to fix it in so many places throughout the OS that by the time you're finished, you might as well have scrapped Haiku the app_server and started with a new OS userland completely. (Edit: I let my hyperbole get away from me here. There should be little need to rearchitect the core OS. Strikeouts show the original text.)
• Power. Haiku does not have a heavy hardware requirement. In many ways, it's far lighter than Windows, MacOS, and many distributions of Linux. One of the problems, however, is Pervasive Multithreading. Haiku inherited this philosophy from BeOS, making multi-threading much easier than on other operating systems. This approach may have memory and performance problems on the Tablet's highly variable CPU speed and constrained memory.
• CPU scaling. This one would go the furthest for power-savings, and would involve a relatively small amount of tricky kernel code. Outlying worries would be unexpected behavior in userland when the CPU slows down.
• Lack of physical input devices. Really, this is a minor concern. A virtual keyboard service would need to be added to the OS to bring up the keyboard when the appropriate. Support for a touchscreen can be likewise added. I can imagine this easily being a Google Summer of Code project.
• Hardware Acceleration. Expecting and enforcing it is a serious advantage in the mobile space. iOS proves this over the more traditional graphic stack on which Android relies. While OpenGL was built-in to BeOS and thus, Haiku, it is by no means enforced. There are already efforts to implement this, but hardware support remains a difficult issue. 

Of course, there's one huge issue every alternative OS maker is facing. It's not the lack of apps, it's the decreasing importance of the OS itself. The Internet and HTML5 is set to consume more and more of the traditional application space. Google has gone to the extreme with ChromeOS. Your API is HTML, Javascript, and CSS, not BWindow, and BView.

What are alternative OS devs, like the ones behind Haiku to do? Personally, I think everyone in the non-proprietary space can do well by abandoning the idea they can "win". We probably won't topple Windows, Mac OS, Android, or iOS. However, we can have a lot of fun, and raise crazy, new ideas of computer interaction to fruition.

While our code may not change the world, maybe our ideas will.

So the Techworld is abuzz with news of Research in Motion's Blackberry Playbook. (Pictureful review here.) The 7-inch device is the newest entrant into the quickly crowding market of Tablet PCs. Unfortunately, the Playbook's intial impressions all come back the same way:

"It's half-baked".

Let me expand upon that. While the hardware is very nice and considered a solid contender, the software experience leaves a lot to be desired. This is to be expected as the operating system is not Blackberry OS -- contrary to branding -- but a new os based on QNX. QNX is an embedded OS with a long history of running mobile and critical computation platforms for the better part of a decade. All of that QNX goodness, however, is backend. The user-land of the device runs (if memory serves) Adobe AIR, a repackaging of the Flash platform.

The UI is very clean and attractive. It takes cues from Blackberry OS 6 as can be seen in the home screen. Many bloggers have accused the Playbook of "stealing" ideas from Apple's iOS and HP's webOS. In the former's case, the blogger was referring to how one can rearrainge icons on the screen by holding down an application icon. The latter case refers to a swiping gesture from the bottom to the top of the screen to close an application. Really?

Are we really arguing about this? While I may be critical of Apple these days, a good UI idea is a good UI idea -- theft is the highest form a praise in this industry. Just because someone else implemented the idea first, does not mean that everyone else must implement something completely different. In fact, I find the opposite to be the case. Users become accustomed to certain gestures when interacting with a device of a certain form factor. Holding down an icon on a home screen to reorganize or swiping upward to close an app seem intuitive gestures to me. They are simple and elegant. Creating another gesture to do the same thing (where no patent prevents, or is worth the court battle) is a good thing for the users. 

All of this gets into the notion of User Interface Patterns. Users expect a device to behave a certain way based not on it's OS, but on it's form-factor. Arguing that a good, intuitive, and elegant UI pattern is "unoriginal" is stubborn and short-sighted. With this sort of thinking, if one OS invented the mouse today, the blogosphere would erupt in ire at the first copy-cat. Please, get over it.

I ran across another sort-sighted argument the other day.

While checking my twitter feeds, I noticed a retweeted articule from the Huffington Post about why ChromeOS is a "stupid idea". Those of you that have listened to me on the OSNews Podcast know that I myself was sketptical when ChromeOS was first revealed. I couldn't possibly see how an operating system that consists entirely of a web browser would be of any use.

Then my job changed.

I work as an IT education developer. I write classes and training material for multi-million dollar enterprise software. For most of my career, each class I have written revolved around a particular product. I would write modules for each major feature of the product, breaking it down and educating students how to use and configure each feature.

About a year ago -- some months after my company was acquired by my current employer -- my boss informed me that I was to be given the new Cloud Computing cirriculum. At first, I assumed that it would be yet another product class. Cloud is so new, however, that a great deal of conceptal understanding is required in order to get started. 

To educate myself, I decided to throw myself into it. I switched to in-browser applications where I possibly could. I subscribed to twitter feeds, blogs, and podcasts. I buried myself in the industry in order to understand what in the hell this Cloud thing was all about.

My opinions on ChromeOS were formed before any of this happened. Instead of being released at a breakneck pace -- as many bloggers assumed -- ChromeOS's release plans have been a snails saunter at best. I had initially taken this as a sign of eventual failure given the metoric rise of the Android platform. 

Then Chrome 10 hit. 

Chrome 10 introduced the Chrome Web Store -- an online repository of downloadable "apps". HTML 5 actually specifies this facility. Web sites can specify which files may be "cached" so that when the bowser is offline, the site can still be used. Perhaps not particularly useful for Facebook or Twitter, but think about Google Docs, Zoho, Producteev, and other SaaS (Software as a Service) applications. It is conceivable that you may still want to use these to get some work done while your Internet connection is down. These are perfect cadidates for HTML5's offline caching.

Except there's a problem.

Not a technical problem, a human problem. Users aren't aware of this facility at all. Granted, they may have been told, but how the spec lays this out leaves a lot to be desired. According to HTML 5, offline cached pages are available by entering in the web site's URL. I don't know about you, but the idea of trying to enter a URL in when I'm offline feels....weird. I expect the site not to be available because I know the computer is offline. If users aren't in the dark enough, developers may overlook this feature as sparsly used, or too complex to implement.

When the Chrome Web Store was introduced, many people thought the "apps" were just fancy bookmarks. Why even have them and introduce all the code cruft that comes with them? If you read Chrome's own developer documentation, you'll discover there are many motivations that suggest that a bookmark is simply not enough for a SaaS application. SaaS applications require special access permissions to browser features (configuration, storage, history) in a way that a mere bookmark cannot provide. When looking at an app on the Chrome Web Store, you'll notice the permissions in a sidebar on the right.

But it goes further than that.

Chrome apps are really *.crx files -- basically a ZIP file with another extension. This is a common practice given the ZIP algorithm's speed, features, and cross-platform ease of implementation. The *.crx files contain at minimum, an XML manifest file. This manifest specifies the name of the app, the icon, the permissions, and where to load it from. It's this last field that makes Chrome apps different. 

Chrome apps come in two flavors, one in which all the files that make up the meat of the application are available elsewhere on the internet, the other in which the code is in the *.crx file itself. This latter mode enables dabblers and developers to create and publish HTML 5 applications without the need to drum up the web hosting themselves. Many Clock and Stopwatch application on the Chrome Web Store refer to no external site at all.

Chrome apps are not meant to replace the offline caching mechanism of HTML 5. In fact, they are their to make it obvious and intuitive. A good example of this is the application 3DTin. This application was originally packaged entirely in the *.crx file. As the app gained in popularity, the developers wanted to make it available for other browsers such as Mozilla Firefox. But, *gasp!*, *.crx files aren't understood by Firefox at all! 3DTin came up with a brilliant solution -- the application was rewritten to take full advantage of offline caching and uploaded to a public web server. Then, the *.crx version was stipped of all of its code, replaced with a reference to http://www.3dtin.com. Now the Chrome app for 3DTin instucts the browser to go to www.3dtin.com, and the web site instructs the browser which files to cache for offline use. This allows the developer to maintain only one "packaged" version of the app, whereas the *.crx is just a reference. 

What about that HuffPo guy?

I've learned a lot about Cloud, HTML5, and Chrome in the last year. My understanding is a lot more nuanced. ChromeOS hasn't seen a wide release yet because the world in which ChromeOS would work best in, does not yet exist! Google is creating this world through the use Chrome of traditional desktop platforms, and the Chrome Web Store. The Web Store is an astonishingly clever way of making this happen. Google is waiting until the application space provided by the Chrome Web Store has matured enough to make ChromeOS viable. 

Drat, lunch is over. Back to work.

I feel I've lost myself over the last several years. I've lost my ability to write, to draw, to program, to create. Most nights pass away quickly and quietly with movies, music, or podcasts. It's difficult to focus on being creative when you work in a content production industry; by the time the evening comes, there's little energy left to do more.

I've taken a few steps hoping to reorganise my life. I work from home now, eliminating communting time and vastly reducing lunch expenses. I've dropped my gym membership, opting instead to exercise at home using a cyclist's trainer and a handfile of other equipment. I have tried to add more quiet time to my schedule in the hope that the silence will allow for a calmer mindset. 

Even with all of this, I still find it difficult to focus on the creative efforts I once enjoyed. With age, in my case, came timidity. So much so that writing a simple blog post can be an epic struggle against thumbing the Delete Key. Friends and co-workers alike have suggested that I'm simply overworked, and that a long vacation and a change of scenery would snap me out of my doldrums. 

The thing is, I've had vacations. I've had comp time. I've had holidays. None of these have helped. The trouble is not where I am, but how I am. Fixing that will take much, much more time.

And require much, much more effort.