Is Oracle Doing what Sun Couldn't? I Can't Bring Myself To Think So.

I'm staring at my mug with the image James Gosling created - Tux standing in front of Sun's gravestone, consoling Duke's loss. Sun left us too early... it was always an amazing playground of tech, giving us cool stuff like Jini and JMX. I was ill at ease with Oracle before their acquisition of Sun, and now I'm even more so.

Still... I noticed that Oracle recently has done something that Sun hasn't been able to do. While Sun tried to govern Java with some sort of loose democracy known as the Java Community Process, it never was able to get consensus with the group and move forward. Perhaps Oracle's benevolent dictatorship is what the JCP needed - for now they have been able to get IBM to join forces with them and work on development of the OpenJDK.

This is a pretty big deal, as Gosling notes. Not only does this collaboration accelerate open Java development but this also possibly reduces fragmentation since IBM will be scaling down their work on the Apache Harmony JVM. RedHat's IcedTea implementation is already married to the OpenJDK codebase, and without IBM's backing of Harmony the OpenJDK implementation quickly becomes a de facto standard.

If Oracle can light a fire under the JCP and put significant engineering efforts around an Open Java development tookit... I dunno. Maybe things will turn out all right after all. I'm still pretty hesitant.

A Return to Code

My blogging juice is running low as of late. For the past several months I have been getting paid to blog... which is weird. Now the din of typing that has usually prefaced a post here ends up being posted elsewhere. It's awesome to get paid for something you love doing, but it does mean that free time is sparse. For example, it has taken me a good four days just to write this post.

In the pauses between work and life I've been trying to look at DeskBlocks again. I still really like the idea: a physics sandbox that plays directly in your window manager and interacts with your desktop. I have a working version on SourceForge, but it requires a version of ODE and has a few bugs. I would like to ensure it plays nicely with multi-monitor setups as well, especially on dual displays with disparate resolutions.

Of course my code has rusted in the months that it has gone untouched, and the algorithms I used to constrain the physics to two dimensions (instead of ODE's three) have become antiquated. 2D is a much more out-of-the-box affair now, and building with the newer library versions brings an instant segfault on object creation. Qt has matured over time as well, and I need to leverage the newer functionality of Qt 4.7. Not to mention my C++ brain has atrophied and need some exercise.

I'm glad I wrote down most of my thoughts in a design journal - a discipline I've been doing for a few years now both at work and with personal projects. Old notes have saved me on a number of occasions, especially in scenarios like this where I'm picking up something after a long pause.

I'm not sure how much progress I can make when my development time will only come in fits and starts, but I'm hopeful I can finally release something worth playing.

ALSA Good in MythTV, I do the Hulu!

I'm a very happy puppy. Now at least.

There's a re-occurring mystery that happens with my MythTV boxes. Several versions and several builds of Myth work fantastically when suddenly KAPOW - the recording stops. Oh sure, it says it records crap, but then I try to take a look and nuttin' is on the file system. The only recourse I've been able to find so far is to drop the entire database and re-build it from scratch. Ick.

This happened to me recently and I took the opportunity to take a deeper dive on getting the hardware working correctly. When I first configured my latest Myth box I settled with a non-working ALSA configuration and just piped audio to the OSS compatibility device at /dev/adsp. It worked, even though the DTS or AC3 surround sound pass-thru didn't work. This time I hunkered down and really tried to get the thing to work.

I dug deeper into ALSA's digital out documentation, going through every step they illustrated to find how I could patch MythTV's audio to ALSA. I pointed MythTV directly to spdif by specifying ALSA:plug:spdif for the audio output device. It works fantastically now and feeds pristine audio from the pcHDTV HD-5500.

Once audio worked I wanted to up the ante a bit. I've given up on my cable television service and wanted to see if I could supplant it with Netflix and Hulu. Netflix works great through the Wii and Hulu's Desktop app works amazingly well on Linux. It was a straight-forward process to launch Hulu Desktop right from within MythTV and even bind the same remote commands in Hulu. At first sound did not work: Hulu Desktop uses the default ALSA output instead of letting me explicitly define the spdif channel. No matter - after a little bit of checking I just created a PCM default by feeding the mythtv user account its own, custom ~/.asoundrc containing:
pcm.!default {
type plug
slave.pcm "iec958"
}
This had ALSA make spdif the default output and Hulu Desktop was happy. Woohoo!

One additional problem however... for some reason both Hulu Desktop and MythTV rendered a bigger window than my TV could display. For some odd reason my TV only displays 97% of the content rendered by my video card. For example, if I tried to set my resolution to 1920x1080 (the maximum supported by my television), then MythTV's interface would be slightly too big to fit the screen - 57 pixels would be cut away at the left & right, 32 pixels trimmed from the top & bottom. To get around this I had to tell both Hulu Desktop and MythTV to shrink by 3% and then re-center themselves. For a 1920x1080 resolution this meant having MythTV shrink to 1863x1048 with an x,y offset (a.k.a. window origin) at 29,16. For performance reasons I switch to a 960x540 resolution for Hulu Desktop, which means a 932x524 window size starting at 14,8. Once I made those size & position tweaks everything fit perfectly.

After a ton of trial and error I now have 5.1 channel surround sound for recorded HDTV broadcast streams (when available) and have Hulu Desktop & Netflix running on the living room television. Now I'm happy... no more cable TV, less commercials and tons of stuff on demand. If only Netflix would provide a Linux-friendly player the living room setup would be in pure harmony. Until then, I've got the closest thing to it and a smaller bill every month.

openSuSE 11.3 - And The Rage Returns

I really want to love openSuSE. I really, truly do. Things were going so well between us... I was very happy with openSuSE 11.2, so much so that I installed 11.3 the same day it dropped. Things looked even more polished - no missing icons, no segfaults, everything operated cleanly and worked well. I went to install my favorite SuSE applications... and they simply weren't there anymore.

First let's discuss SaX2. I love SaX2 and how it makes XOrg configuration so automagic. Yet SaX2 is no longer provided with SuSE distributions. The openSuSE team did announce that this was happening, supposedly because "automatic configuration and dynamic reconfiguration mechanisms have been developed such that today the tasks that SaX2 was able to do are done fully automatically on the fly and can be modified from within a desktop session." They might have a point... I do use nivida-settings more than SaX2 now. Oh well... I'm willing to let it go.

However one thing I wasn't able to let go of is SCPM. It went missing without so much as a trace and a profile management package can't be found in any repo for openSuSE 11.3. This was a major product differentiators for ALL SuSE distros, and for it to be missing is a huge shame. Now it is even harder for me to switch between configuration profiles for presentations/home/work, as they take wildly different network configurations, display configurations, peripheral configurations, printer configs, on and on and on... The omission of SCPM is pretty grave.

I went to find solace in my Really Slick Screensavers. I added my missing KDE4 screensaver entries and expected them to work as they always have. Then I ran across yet another omission - the KDE xscreensaver compatibility applications were missing as well. This omission was even more curious, as they are missing in the binary packages but are present in the source packages. I re-built the RPM from source, re-installed it and the xscreensaver compatibility layer appeared. Odd... and now I'll have to re-do that step with every patch & upgrade.

I don't know what to think of 11.3 yet. On one had it works extremely well and the longer release cycle appears to have served them well. Still, I can't help but feel that some things were omitted to simplify the packaging of the distribution... and that could be a bad omen of things to come.

Into the Breach

Seriously? May is gone already? Dang.

I've noticed an interesting trend among black hats lately, particularly with hosted software solutions or software-as-a-service entrants. First Jira had an exploit and a few large compromises, not to mention a flurry of fits and starts when Atlassian left an old password database out in the open.

Not too soon after it was revealed that Splunk had suffered a similar compromise, revealing user passwords. While the security hole itself was something Splunk was responsible for this does indicate a growing trend of attacks against hosted software.

It is easier now than ever to host a web application, but lil' thinks like multi-tenancy and browser security contexts are not easy nuts to crack. It may be generally believed that smart minds elsewhere have figured it out, but we're rapidly finding out that behind every webapp there is a seedy crew trying to hack through it.

So Many Cores, So Little Time

My new work laptop is a ThinkPad W510... a Core i7 Q 720 at 1.6GHz. It has four hyperthreaded cores which /proc/cpuinfo allows me to monitor as eight... meaning my system monitor looks awesome.

Now I'm at the bleeding edge (I guess) of hardware, as now everything requires the latest drivers. I had to manually acquire the firmware for my wireless NIC from Intel directly, then build the Linux wireless drivers from source and install them. Luckily the process was surprisingly easy... it was just that I had to track down and download kernel sources, the GCC build chain, firmware and the wireless driver package without Internet access on the laptop. Still, once that was done the Linux wireless source configure/build/install was quick and easy.

I also had to go directly to NVIDIA's beta driver portal and get the very latest binary drivers for the GPU as well... the console itself was being corrupted by display errors. Again, not hard to fix, just another step.

In the age of everything "just working" on Linux distros I was glad to see that the ancient art of configure/make/make install is still being practiced... in fact it works better than ever.

Eclipsed by a Bean Maven

I've long been a fan of NetBeans, but for the past several years I have had to use Eclipse. Nearly all of the projects or organizations I've walked into have had pre-existing standards and ways of doin' stuff, and the worst thing you can do as a greenhorn in a company is try to switch horses mid-stream.

Wow... I get a triple combo score for clichés there.

Now I get to bootstrap a development team and decide what we use. The awesome thing is that there are now something like elebenty kabillion IDEs, RIA frameworks and rapid application environments. JSF no longer blows. Everyone uses the same build files now. XML hell is now in the rear-view mirror. Vendor lock-in isn't what it used to be thankfully enough.

When I started building out projects I went for an IDE with tight Maven 2 integration, JSF 2.0 support, Java EE 6 interwoven and nice Subversion tools. I imagined that I'd be heavily leveraging plugins from the Spring IDE project and plugins from JBoss, notably the Drools Workbench. All this plugin support caused me to initially lean towards Eclipse.

As I went further along I also started using GlassFish v3 instead of Tomcat, exploring JavaFX and increasingly using Maven 2 for continuous integration and artifact generation. I didn't really use the features of Spring IDE at all, and while I did use the Drools Workbench I ended up doing more decision-table type stuff, making drl's easier to manage. Ultimately a deciding moment came when I needed to do a very quick-and-dirty desktop application with a simple user interface... something that just needed a logo, URL text field, username and password. For the life of me I couldn't find any free/OSS plugins for Eclipse that let me create a quick JDesktop or Swing application... at least within the 45 minutes that I had available. After pulling out my hair I had a sudden flashback to the good ole' ConsultComm days and reminisced "boy, creating UIs in NetBeans sure was swell." It was at that point when I tried to think of any reasons why I was sticking with Eclilpse... and came up empty.

I've switched to NetBeans, which the IDE itself made extremely easy with it's Eclipse workspace synchronization. Read that line again... synchronization. I know! Mind blowing! It doesn't import the project, it allows your project to remain in the Eclipse workspace while also being mantained in NetBeans. Easy!

All the UI goodness I remembered was still there. In no time flat I had created the entire UI and help menus. Not once did I consult a HowTo or documentation, instead it all immediately made sense. The entire project was done before lunch.

I have shifted all of my development to NetBeans now, despite the fact that I can't be sure where its future lies. I don't care. I'll take advantage of an easy-to-use IDE as long as I possibly can. If I switch back to Eclipse in the future it will like be because I was forced to... just like every other time in the past.

As for standardizing on a development environment: I've learned that no one IDE fits all. Every developer has a preference, and with Maven 2 reaching near-ubiquity it doesn't matter nearly as much as it used to. I say let every developer chose his or her IDE, just pick the one you work most rapidly and naturally within. As long as I can build it with mvn on the command line I just don't care.

Camel Integration

Sweet monkey spit... did I just miss January entirely? Is it seriously February? Dang.

One thing I have been researching lately has been enterprise integration frameworks. I'm a big fan of thinking in patterns while doing design and development and that goes double for architecting systems as well. When I sit down to architect a system I do my best to first think in terms of Enterprise Integration Patterns, then in terms of the Gang of Four's Design Patterns, and then in terms of implementation.

For a current project I've completed the architecture and a good chunk of design, so now I'm looking at implementation. I need to tie together a lot of disparate views to a lot of disparate services, which originally sent me down the path of evaluating Enterprise Service Bus products. I liked the content based routing using Drools utilized by JBoss ESB and ServiceMix. The orchestration of Chainbuilder was also a nice move forward. All had proper integration with naming and directory services as well. Ultimately, however, I found that most of the functionality within an ESB solution simply wouldn't be leveraged; the authentication and authorization model would need to be refactored, I didn't really need transactional support and there was no business process management to speak of.

I really just needed component adapters, translators and content-based routing. Slimming things down to just an integration framework left two main choices: Apache Camel and Spring Integration. Both offered the decoupling I needed and mirrored the Enterprise Integration Patterns I had already used in my architecture layouts. Even though these two frameworks are remarkably different in their implementation they are difficult to contrast. The rumor is that this similar-but-different approach is well known, in that the Camel team originally envisioned becoming a part of Spring. Of course Spring decided to roll their own ultimately to better fit their view and style (especially in a Spring 3.0 world).

Probably the best comparison is provided by actual, concrete examples of event notification on Hendy Irawan's blog: one written with Spring Integration, another with Apache Camel. The examples are written to leverage Spring Remoting, a remote method invocation mechanism not unlike Jini's remoting mechanism. While the examples do have to jump through the hoops of creating a proxy object, the meat of the comparison is in the application context of the two examples. Note that the Spring Integration configuration is a bit more readable and maps more distinctly to an integration pattern layout. The Apache Camel configuration just looks like a standard Spring bean context, however it uses URIs for connecting components rather than using dependency injection to connect them.

Ultimately I like the convention of having endpoints addressable by URIs rather than keeping them as actual bean references. For my tastes this makes things more agnostic (even from Java itself) and more coherent. Having URIs indicate addressable resources is a convention most developers are familiar with, if not just by writing curl scripts.

There are a lot of facets to view when attempting to evaluate integration frameworks and service buses. Gunnar Hillert's blog can give you a small peek into how wide of an ecosystem this really is - you can't just perform a straight-forward SWOT analysis any more. One must always architect first, design second then look at what implementation can get you their with ease and speed.

Synergy+, Because I Can't Work Minus Synergy

After upgrading my desktop to openSuSE 11.2 64-bit, I noticed I couldn't find any suitable Synergy packages to share my desktop's mouse & keyboard with my laptop. I tried to build the packages by hand, but the 64-bit libraries and newer glibc/std libraries confused the build. Synergy itself hasn't been updated in nearly three years, so it appeared I was out of luck.

I have become pretty reliant on Synergy however, so I kept searching for a solution. I finally came across Synergy+, a maintenance fork of the Synergy 1.3 codebase. Not only had the compile errors been resolved, but they offered pre-built 64-bit packages that fit like a glove. Bugs were fixed and Synergy is working much beter than before. Sweet!

Java EE 6 - Gee, 6?

Java Enterprise Edition 6 was just released, even with Oracle's possible acquisition of Sun looming on the horizon. In the past I've seen J2EE and Java 5 EE releases come and go whilst I went on not caring. It wasn't because I didn't need anything more than Java's Standard Edition... I do... but the Java Enterprise Edition releases always seemed to be released with features I needed nine months ago and found in other frameworks.

I decided to take more of a look within this release and give it a fair shake. This release had a lot of nice stuff but was still playing catch-up with other tech: JPA starts catching up with the functionality offered by Hibernate, JAX-RS (RESTful Web Services) is finally produced as an answer to the myriad of other REST frameworks and dependency injection finally gets introduced into Java proper. All of these additions are features that were already offered by alternate libraries over a year ago (some of them more than five years ago) and are just now becoming standard.

Inversion of Control isn't the only elder pattern that finally debuts in Java EE 6. Asynchronous responses appear throughout the new Enterprise Edition, finally allowing threads to stop blocking subsequent operations. Asynchronous processing is finally available in the Servlet 3.0 spec so inbound HTTP requests don't have to hang forever while they await all the info to formulate a response. Session Beans can now be invoked asynchronously so EJB execution doesn't consume a client thread and eat up threadpools. JSF now has AJAX support for asynchronous webapp calls. REST-based Web Services allow for Web Service exposure with much less resource utilization and much higher concurrency through more streamlined asynchronous HTTP calls. All of these features not only have been present in alternate libraries for some time, but entire protologisms and design patterns have been honed to allow for just such asynchronicity. Comet and callback methods have been a predominant pattern for some time now, although Servlet 3.0 is the first time a Java Enterprise Edition has allowed for asynchronous Servlet processing. Now that WebSockets are becoming more prevalent Java Servlets are going to need to catch up to everyone else yet again and in short order.

Am I even tempted by this release of Java Enterprise Edition? Maybe kinda. I like annotation-based models, as I've seen how deep XML hell truly goes. JAX-RS annotations are a compelling alternative to JAX-RPC, and the new Bean Validation annotations would likely be very helpful. Asynchronous EJB invocation, along with a more minimalistic and annotation-based EJB spec, may even convince me to finally give Enterprise Java Beans a try once more.

I already use JPA, JAXB, JMS, JMX, JAAS, JAX-RPC, JavaSpaces and Servlets/JSPs/JSTL but in more of an a la carte sorta mechanism, intermingled with Spring, DWR, Hibernate and Camel. Now that I've typed the previous line... I realize that even though I've never intentionally downloaded the Java 5 EE package from Sun it seems I've been using Java Enterprise Edition all along. Weird. I guess it has slowly seeped into the crevasses of my frameworks, unintentionally filling out the rest of the libraries I use. Now that we have REST support and asynchronous context... I might walk the final yard and intentionally download it this time.

Passwordless Login Haters

Password-less logins via an X11 login manager has always been a misunderstood topic. Just search for "passwordless xdm" and you'll see tons of flamewars started by someone innocently asking how to allow a user to login to KDE or Gnome without having to remember a password. Without fail, a number of people will decry the very thought and deem those in question complete idiots who subvert the very laws of nature, security and well-being. I was involved in such a discussion a while back on a newsgroup, and the result was pretty typical. Instead of saying "I don't know" the poster derided my efforts and said this was the biggest security hole ever invented since... the hole... or something. After explaining what a kiosk was the thread devolved into my posting etiquette. Point and match, sir.

When it comes down to it people don't understand Linux' password authentication mechanism. The PAM subsystem allows for a number of profiles based on who is requesting authentication and authorization. SSH, FTP and yes KDE/Gnome login managers all have different authentication profiles that determine how and when a user is authenticated.

Allowing a two year old to just click on her face in the KDE login screen doesn't open unbridled access to everyone in the world. If you've disabled remote X11 logins, turned off X11 tunneling via SSH and bolted down remote access then only local users physically at the keyboard will able to login without a password. If that same username tried to SSH in to the box they would be greeted with a password, since the passwordless authentication only applies to KDE's login manager.

One could breech the KDE login manager for access by this user, but that's a whole other story. Ultimately what people don't understand is just because a username doesn't need a password to authenticate on a local desktop session that doesn't mean the username will never need a password to authenticate via any means available.

Enough of that tho. Ultimately I'm getting on this soapbox because I had to alter openSuSE 11.2 to properly allow me to have per-user passwordless logins via KDM. With a stock openSuSE 11.2 install you have two choices for their desktop managers: you either require passwords for everyone or you grant passwordless logins to everyone. In my kiosk I just need a couple of low-privilege users to be passwordless; the rest require logins.

Something SuSE has always loved to do is override configuration files with scripts that freshly parse settings from /etc/sysconfig every time they're used. In this instance SuSE runs the script /usr/share/kde4/apps/kdm/read_sysconfig.sh every time it starts the KDE desktop manager, wiping out old configurations and procedurally generating new ones. Even if you know what config file to change it doesn't do you much good - it will get wiped out when KDM starts. On top of that the default /etc/sysconfig/displaymanager value for passwordless logins (DISPLAYMANAGER_PASSWORD_LESS_LOGIN) is just true or false... you can't set an arbitrary user.

I modified /etc/sysconfig/displaymanager to accept more than just a yesno value... instead I told it to accept an arbitrary string. Next I modified /usr/share/kde4/apps/kdm/read_sysconfig.sh to see if the DISPLAYMANAGER_PASSWORD_LESS_LOGIN string was set to "no." If it was, don't enable passwordless logins at all. If it was not, enable passwordless logins and allocate the string to be the list of users that have password-less logins.

The modification was minor - it was just altering:

if [ "$DISPLAYMANAGER_PASSWORD_LESS_LOGIN" = "yes" ]; then
echo "NoPassEnable=true"
echo "NoPassAllUsers=true"
else
echo "NoPassEnable=false"
echo "NoPassAllUsers=false"
fi

to be:

if [ "$DISPLAYMANAGER_PASSWORD_LESS_LOGIN" = "no" ]; then
echo "NoPassEnable=false"
echo "NoPassAllUsers=false"
else
echo "NoPassEnable=true"
echo "NoPassUsers=$DISPLAYMANAGER_PASSWORD_LESS_LOGIN"
fi


in /usr/share/kde4/apps/kdm/read_sysconfig.sh.

Now I have passwordless logins and still retain security... despite what others may think.

openSuSE 11.2 (No I Will Not Spell It Their Way)

I installed openSuSE 11.2 at the beginning of this week and am glad to finally be done with unsupported KDE 4.x packages. Installation took much less time than previous incarnations, and boot time, shutdown time and suspend time is ridiculously faster.

One exceedingly nice item is that a native KDE 4 Network Manager is finally included with the distro. Setting up a wireless connection was just fine once I got the necessary firmware installed for my wlan adapter and VPN connections were managed correctly for the first time in a long time. Remote routes specified by the VPN concentrator were applied (w00t!) and negotiation took only one or two seconds.

Packages are stable and fairly seamless - moving in to this install has also taken much less time than previous versions.

Fonts scale particularly well. Finally 96dpi is obeyed on my monitor and both GTK and Qt apps look fantabulous.

Things are painless, stable and work out-of-the-box. openSuSE 11.0 was not without hitches but worked great overall - and openSuSE 11.2 is great with no compromises.

Picking Apart Android's Engine

Harald Welte's blog recently had a span in the limelight thanks to a recent LWN article that highlighted the quote "Android is a screwed, hard-coded, non-portable abomination." The retorts are based on Matt Porter's "Android Mythbusters" presentation at Embedded Linux Conference Europe; Matt highlights features of Android that illustrate it's isolation from usual embedded Linux systems.

The presentation highlights not only the Linux kernel but other parts of the OS stack such as tools, common libraries, device initialization and SysV compliance. Both Matt, Welte and most commenters on LWN's article seem to forgo the familiar mantra that GNU is not Unix and discuss Linux in terms of both the kernel and a common software stack. Yet Google does not seem to be interested in the entire Linux environment but rather the core kernel itself. If you watch only the first minute of Google's Android Architecture Overview video you'll hear what Google is taking from Linux and why. It seems (and browsing through the source seems to confirm) that they're largely interested in the Linux kernel's driver modules and not the entire toolchain. Maybe for both for licensing and pragmatic reasons Google would rather forget about LSB compliance and SysV support; they just want a robust driver model with reasonable userspace security.

A site or forum other than LWN would take Welte's comments as kindling to a giant flame war. Instead (the vast majority of) LWN users offer insightful, more considered posts. Several commenters note that Google is avoiding the GPL whenever humanly possible, instead opting for a more permissive Apache Software License. Given how Android is intended to be re-used by OEMs as widely as possible this makes a good deal of sense, and may explain the avoidance of glibc. If we pare away the glibc and SysV arguments we still see a lot of hackish hacks in Android: hardcoded device policies, missing header files and broken unit tests. Hopefully this has been addressed in Android 2.0... the last tree I've gone through was after the 1.6 release.

Do these warts make Android prohibitive for developers? Not really. Bear in mind third-party development is meant to be confined to the Dalvik environment and Google's Android SDK. Native development is definitely allowed and enabled for Android, but 99.9% of all developers should be creating Java apps for the Dalvik VM. The VM sandbox should keep both users and developers safely away from any rough edges of the OS' internals. Still... Google often promotes the fact that each process runs in its own, isolated virtual machine as its own user. With so many Dalvik instances running at once, one would imagine that a little inter-process communication might go a long way.

A Battery of SMS Problems

I've enjoyed the Hero so far - it's been a nice device. The battery life had left something to be desired however - it only could make it about eight hours. I also noticed that SMS messages just... stopped. There was silence whenever I sent a message via the old short message service.

Then I started reading about a litany of problems with HTC's SMS client. First, several found that the "Messages" app never lets the handset suspend. While the display may flicker off the engine keeps revving, eating up cycles and draining the battery. In a maybe related issue, many people have also been reporting their Hero cannot receive SMS messages, although this doesn't seem to happen for everyone.

I installed Handcent SMS for Android and have been using it in lieu of HTC's Messaging. It is definitely a superior SMS application to begin with and it is much more gentle on the battery.

I contacted Sprint support about the lack of inbound SMS messages, and they had me update my handset profile over the air. Basically I had to:

1. Shutdown the handset and remove the battery for two-ish minutes
2. Start up the handset, open up the Android settings -> About phone -> System updates -> Update profile and update yon profile
3. After the profile update, reboot the phone again

I'm not sure if having a service rep on the line is integral to the process or if they tweaked my profile. Maybe they did and I was just sync'ing up the handset with the central office. Things seem to work now however.

I've had a few crashes, especially with Android widgets embedded in SenseUI. All-in-all it's working wonderfully however. Astrid has been great for organization, and Meebo has been a serviceable IM client. My one dearest wish is multi-protocol Off-the-Record Messaging for Android - then I would never need to turn on my laptop again.

Paused For a Moment, Then Went On

Stopped by the local Sprint Shoppe on the way to/from work today. I decided to try out the Samsung Moment and see how it compared to my Hero.

The reviews of the Moment are pretty much on target. Most people noted that the Moment feels more "plastic-y" than the Hero, and I now see what they are talking about. There are a number of open seams, creases and joints that join several plastic components that comprise its shell. Even the rubber covers over the headphone and USB jacks add to the effect, making it seem like you're holding an enclosure that's a composite of several black, plastic slabs.

Aesthetics aside, the OS itself isn't much. I never really appreciated all that HTC did with its SenseUI; I kinda forgot about its revamped dialer, lock screen or music player. The Hero's Android "extras" integrate so well you tend to delude yourself into believing that it represents a stock Android 1.5 experience. Quite a shock to pick up the Moment's Android 1.5 build - it has the same awkward lock screen, dialer and window components that come default. Not a killer, but it makes you less likely to show off your phone to the nearest nerdcore.

The AMOLED display is nice, but not NIIIIIIIIIIIIIIIIICE like everyone else seems to exude. Contrast is spectacular and images are vivid (especially with video), but it's not a huge improvement for day-to-day operations. True, this should theoretically help battery life, but given the stats it seems the 800MHz sips on the saved juice. I had no problem with the touch screen's sensitivity - it was just as responsive as the Hero's screen.

A fold-out keyboard is very nice and is something I've really wanted, especially since I've been using a Nokia n810 for the past 18 months. I didn't have any issues with the Moment's keypad, and I didn't find the layout the least bit cumbersome. The space bar, even though it is two individual buttons "glued together" under a single piece of plastic, was just fine. Breaking apart the alpha keys so they straddle the space bar didn't bug me a bit; I was quickly typing things out rapidly after only a few seconds.

Samsung's 800MHz SoC is what really saves the day. By upping the clock speed and putting the cellular modem on a separate piece of silicon multi-tasked applications ran much faster on the Moment. This seems to be its crowning achievement - I could run several apps, side-by-side, with very little lag. Screen transitions even went off without a hitch.

One thing I was confused about was how the integrated Moxier Mail was going to work with Exchange. After dorking around with it a bit it seems to work much in the same way that HTC's Exchange client works; the calendar syncs with the native Android calendar, mail is a completely separate app from the GMail app, contacts are imported directly onto the handset. The big difference is that Moxier appears to support many more server-side Exchange options, such as remote searches and tasks. For what I would want to accomplish, it appears Moxier has the best solution until native support appears in Android 2.0.

Speaking of Android 2.0, I asked the manager of said Sprint Store if Samsung was going to offer an Android 2.0 update with the Moment. The manager was very gracious and spent nearly 30 minutes researching the answer and delving into the secret Sprint-only archives, but it was for naught. She could find no sign of Samsung offering an upcoming Android update for the Moment, never mind an Android 2.0 update.

Ultimately the Android 2.0 update was the clincher. HTC has gone on record that it will offer an Android 2.0 update, but Samsung has remained mum. One has to wonder if they'll push out an obligatory 1.6 update then cease Moment support. Many forums (such as XDA and phandroid) appear to anecdotally support this; several users (albeit perhaps fanboys) claim poor support of legacy handsets on Samsung's part, while HTC is still even updating its legacy, flagship Android handset.

The Hero does lag something fierce at times, but at least HTC is tantalizing everyone with promises of an Android 2.0 update. With Samsung remaining quiet about Android 2.0 coming to the Moment anytime soon, one has to wonder if a 50% faster CPU, marginally better Exchange support and somewhat prettier screen is worth it. Let's face it - I'm a sucker for frequent desktop updates and revamps. I simply can't turn down the super-happy funtimes that HTC is promising.

A Little Bit More Self Restraint This Time

Today was Éclair day. Google published the Android 2.0 Release 1 SDK. Verizon announced the first Android 2.0 handset. HTC announced they will release port Android 2.0 to the Hero. On the heels of all this hullabaloo I finally went ahead and picked up... Sprint's Hero.

By all accounts the Hero is waaaaaaaaaaaaaaaay inferior to Verizon's Droid. Even inferior to the Samsung Moment that is being released in mere days on Sprint, the self-same carrier of the Hero. After reading the early reviews, however, it appears that the 800MHz SoC and AMOLED display isn't enough to lift the Moment out of mediocrity.

The Hero's camera does suck, no doubt. And Samsung makes a nice camera. However my biggest items of desire were:

• GPS turn-by-turn navigation, because I can't find my head with a flashlight
• One central, integrated calendar to keep my day straight at home and work
• Exchange integration for work info

It sounds like the Moment's GPS is a bit finicky, flaking in and out at times. Exchange integration is supplied by the very capable Moxier Mail but it doesn't sound integrated into the main calendar interface itself. The AMOLED display reportedly washes out in direct light as well, and the keyboard has added considerable bulk to the package.

On top of this there are several forums that swear up and down that Samsung has a habit of abandoning their handsets, pursuing new hardware releases instead of updating old once. On the opposite side of the scale HTC has already announced Éclair support coming soon, so they appear to have a bit more dedication to their userbase.

The Moment has the hardware in spades, and I hate the fact that HTC's Android handsets use a Qualcomm 528MHz CPU that shares cycles with the modem on-die. All my engineer instincts tell me to get the Moment. However... my engineer instincts also told me to pick the iRiver iFP over an iPod, the n810 over an iPhone, HPNA 2.0 over 802.11b, VIA EPIA over AMD or Intel. A pretty poor track record as far as instincts go. Specs may win on paper, but market share is what gives a device longevity and sustainability.

Droids Are Expensive

So yes, Motorola's Sholes (a.k.a. Droid) is coming October 30th. Its hardware is unmatched and a basis for comparison of all other smartphones on the market. Without a doubt it's a killer handset.

Yet Verizon killed it for me. Pricing things out on each company's web site, comparable monthly plans for Verizon and Sprint cost $102.98 and $69.99 respectively. That means Verizon will cost me an additional $791.76 over the span of a two-year contract, ultimately for less features than what Sprint provides. Verizon's top priced smartphone is currently $199.99 subsidized - so I imagine the price of the hardware itself won't be prohibitive. It's the plan.

Given that Droid will sport a much more impressive CPU, GPU and display than previous handsets - especially HTC's - I would love to have one. It's hard to justify an extra $800 tho, even if that price tag spans two years' time.

Wait a Moment...

My obsession with Android smartphone hardware continues. Because I'm lame.

Sprint is about to have two Android handsets on the market - HTC's Hero and the Samsung Moment.

The hardware couldn't be any more different between the two handsets. One has just softkeys, the other a slide-out keyboard. The Moment has an OLED screen. One has a trackball, the other has a proximity sensor. The biggest difference that I'm curious about is the processor.

The Hero uses the conventional 528 MHz Qualcomm MSM7201A processor, a chipset that claims 3D acceleration to the tune of 4 million triangles a second. The Moment uses Samsung's own 800 MHz S3C6410 which claims the same 4 million triangles per second with OpenGL ES 2.0 support.

I'm not sure who wins, especially since the Hero has an entirely different UI and a lil' bit more RAM (288M vs. 256M). With OpenGL acceleration being about the same... hard to say.

No Donut For You!

Everyone on the Interwebs kinda assumed that the Android handsets that Sprint is due to offer in the coming weeks were going to be based on Android 1.6. After all, Android 1.6 was the first to offer CDMA support... and Sprint is a CDMA carrier. Right? Right???

No such luck. Both Android devices Sprint will release will ship with Android 1.5 with the CDMA codebase apparently backported. Not only that, it sounds like Android 1.6 won't be available from Sprint until 2010 and it won't be an over-the-air upgrade. Sprint's official word on exactly when is just "when it's available".

1.6 has a number of notable API changes but also a number of important features - most notably text-to-speech and multitouch functionality. HTC's SenseUI was an attempt to staple on several features on the 1.5 codebase that only recently became available. Now that Android 1.6 is available some of those SenseUI features are redundant... such as multitouch in the Web browser.

The biggest problem isn't necessarily with the end-user however - Spring launching with Android 1.5 causes huge headaches for developers. Several developers... myself for one... was counting on this product launch to usher in a landscape of 1.6 apps. Without an easy, transparent means of updating to 1.6 (such as over-the-air upgrades) it is also unlikely that the average Hero or Moment user will ever upgrade to the latest OS.

So what's a guy to do? Well... Motorola's Sholes is supposedly going to hit before the end of the year, and supposedly with Android 2.0 (although I doubt that). On the other hand it's launching on Verizon's network, which can be prohibitively expensive.

Sounds like there are no good options right now for an Android 1.6+ handset, unless Sprint can figure out an easier way to push updates.

Hulu Desktop and Linux = Sweet Brain Mush

I hadn't really tried Hulu much... just a few passing searches in their webapp. When they released their Linux desktop client I decided to try it out.

Sweet merciful crap.

I couldn't believe the sheer volume of what they had that I actually wanted to watch. It ran flawlessly in Linux - and their Fedora RPMs installed just fine on my OpenSUSE workstations.

Man... so much completely awesome stuff is being released right now. I NEED MORE HOURS IN THE DAY TO DORK WITH IT!