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.