Technology – Page 17

Palm Pre First Impressions (vs BlackBerry Pearl)

Today I set aside my BlackBerry Pearl for a shiny new Palm Pre. There are various detailed, photo-rich reviews out there, and many more on the way. I’ll skip that, and pass a few first impressions of the Pre, particularly compared to the BlackBerry (Pearl, in my case).

The hardware is quite nice; the size is only a big larger than the Pearl, with a much larger screen. It fits well in the hand. The keyboard is easier to use that the Pearl, having one letter per key. The screen is bright and sharp. The Pre camera is enormously better than the Pearl camera.
The Pre is a bit sluggish, even with the 1.0.2 OS update which is said to improve things.
The Pre’s software is vastly more advanced than the old BlackBerry Pearl I’ve been using; so much so that it makes the great hardware less responsive than the Pearl’s much older, weaker hardware.
The Pre’s gesture recognition seems rather rough to me; compared to an iPhone I found I had to work harder to get it to do the right thing.
The Pre’s browser, while reasonably fast and very pretty, has poor usability compared to Opera Mini (which I used as my primarily browser on the Pearl), or even compared to to primitive BlackBerry built in browser. Both of the latter reformat a web page to fit well on a small device, such that I can read most pages without zooming and without horizontal scrolling. On the Pre, reading a typical web page is an exercise in scroll/zoom tedium.
The Pre’s email client appears to use IMAP for Gmail access. This works, but not nearly as well as the native Gmail client available for the BlackBerry. It lacks the most common Gmail actions (“Archive” and “Spam”). I don’t know if WebOS makes it possible for Google to create a native Gmail client; if so I hope that happens soon.
The most obvious feature in common between the Pre and the BlackBerry is that both support multitasking, unlike the current (as I write this) iPhone. With a couple of button pressed on the BlackBerry, I can flip over to read email while a web page is loading; the same is possible on the Pre (turn on “Advanced” gestures to make it easy).
With the Pre, I’ve made several accidental calls so far. I’m not sure it’s a good idea to use softkeys for placing a call; this is the first phone I’ve used (since my first analog cellular telephone in the early 1990s) to not have a physical button to initiate a call.
So far, most of the Pre applications leave me wanting more features, more options, more ability to adjust the device to be more functional perhaps at the expense of being less obvious. I expect the situation will improve as WebOS advances, and I hope very much that new versions run on this existing hardware.
The main list-of-apps screen on the Pre is almost like that of the iPhone… except that it manages to get the layout not-quite-right in an absurd way. It arranges the icons 4+ rowshigh, while allowing room for only 3 to be fully visible; thus navigating the list requires both vertical and horizontal scrolling.
The App Catalog displeases me greatly, because when it shows apps available as a trial, it does not show the price of the real app. This is perhaps good marketing, but it is also profoundly disrespectful. There are no prices to be seen, and no affirmative indication of free-ness; according go the Palm support page on the topic, you need to nonetheless “know whether the app is free, must be bought, or can be downloaded in a trial version before you buy it.” Many users have been posting “review” which consist of questioning whether the app costs money and how much.
At the moment there are a whopping 2 (yes, two) games in the App Catalog, one of which is a trialware Connect Four from EA.
The Data Transfer Assistant, used to copy data from the old Palm world, essentially does not work for me. It runs and reports success, but my contacts from Palm Desktop do not appear in the Pre. It sync my Google contact “down” though.
The sync mechanism essentially does not work for me. It claims to be linked to my Google Calendar, but events do not sync in either direction. I suspect it is silently failing under the hood, but in order to preserve the beauty of the GUI, hides the errors.

As you can see I am not entirely happy with the Pre. Perhaps it will grow on me over the next couple of weeks, though that seems possible only if a very substantial bug fix software release appears in that time.

Updates, over the next week:

I manually cleaned up my old Palm Desktop data, then manually renamed a file in the Palm Desktop data store, and was able to get the Data Transfer Assistant to work for Contacts. Next, I purged all old events and some new events in my old Palm Desktop data, then got that data in place (with considerable “tapping” on each event, one at a time!) in to the Pre and from there to Google Calendar. After considerable gyration, the over-the-air sync works well.
Prominent multitasking is a very good thing. BlackBerry has had multitasking for years, but I suspect many BlackBerry users never use it.
After many tries, the Pre WebOS 1.0.2 update installed, and is indeed a bit less sluggish.
I can appreciate more with time, how nice the browser looks; but it is still a big step backward for effective use on a small screen, compared to Opera Mini. The Pre is so tedious that I find myself browsing less than before, even though I just got a slick new device.
While it’s tedious to read many sites with the main browser, the site-specific Apps for the New York Times and AP wrap text correctly and are easy to read.
The Pre’s interface for making phone calls is disappointing.
I greatly miss the Gmail email client that I used on the BlackBerry. The Pre’s email lacks very basic capabilities, for example there is no way to delete/archive/file a message without opening it. With Gmail on a 2-year-old BlackBerry it is feasible to handle dozen of messages (read some, don’t read others, archive some off, mark a couple as spam, etc.) in a minute or two, with one hand and typically one keypress per message. With the Pre the same work takes two hands and many minutes, mostly because of the load time to open each message followed by multiple taps to process it.
The Alarm Clock puts a notification icon at the bottom of the screen permanently, for no apparent reason. Hopefully an upcoming update will make it possible to use the alarm without permentantly losing a strip of screen space.
Battery life on the Pre is short. Starting in the morning at 100%, after a long day of sporadic use it is down to 20%.
Battery life on the Pre is really short: fully changed at midnight. 7 AM, down to 82%. Less than an hour of casual use, down to 52%.
I am not at all convinced that touch screens are well suited for cell phones. I’ve found it much more difficult to place calls, answers calls, and avoid accidental operations.

My comments above are surely slanted toward the negative; but as a lifelong “early adopter” my patience is considerable. Perhaps I’ll grab the SDK and work on an App or two myself. At least a portion of the Pre’s weaknesses could be effectively addressed by high quality third party apps.

Update, after a few more days:

I gave up, and returned the Pre. I’ve carried a cell phone since ~1991, upgrading every couples of years; this is the first time I’ve ever returned one.
It’s not you, it’s me. The Pre is a great piece of equipment, for its target audience.
I got a BlackBerry Curve 8900 instead; it is a much more advanced successor of the Pearl.
Compared to the Pre, the Curve has perhaps 100x more adjustments possible, to make it do what I want. It multitasks. It has a physical keyboard of high quality. Its battery lasts a long time. It runs its own (weakish) browser, and also runs Opera Mini. Thanks to Google’s sync tools, it offers a synced calendar and contact list.
The Curve GUI is not as pretty as the Pre; but it is of very high usability, even one-handed.
T-Mobile pricing is similar to Sprint, but T-Mobile includes tethering at no extra cost.

The Right Way to do Monitoring and Mass Administration

Over the weekend I flipped through these slides about Nanite (code), and it got me thinking about system monitoring (again), as well as mass administration tools (Puppet and its younger competitor Chef). The key bit from the talk is the idea of using a proven, off the shelf messaging server (RabbitMQ) as the communication bus among a set of processes running on many servers.

I would like very much to see a piece of software that puts these pieces together:

Monitoring features, like those in Zabbix or other similar tools
Mass administration features, like those in Puppet
Run it over a messaging bus rather than a homegrown communication mechanism

Such a system would allow some very nice improvements:

The messaging bus could provide real time “presence” information.
Urgent events could be sent immediately, rather than polled.
Urgent administration changes could be sent over the same communication channel as normal operations, unlike (for example) the puppetrun mechanism is puppet.
The specification for how a server is configured could be integrated in to the specification for how it should be monitored. This would be an enormous improvement over the current state of the art (in open source tools anywhere) where these two concerns are separated in to tools that don’t talk to each other.

In addition to the feature improvements, I suspect that both kinds of tools (monitoring and administration) would find they can get by with a smaller codebase by outsourcing the communication bus to a messaging server.

gitosis on Ubuntu 9.04 Jaunty

As of April 2009, the gitosis package in Ubuntu 9.04 Jaunty is broken; it fails with an error like so:

pkg_resources.DistributionNotFound: gitosis==0.2

There are quite a few pages and mailing list messages that mention this. I only found one with a good hint toward a solution, which was that it is also a known issue on Debian. Following that lead, I got it working by grabbing newer packages from Debian Unstable:

wget http://ftp.us.debian.org/debian/pool/main/p/python-support/python-support_1.0.2_all.deb
wget http://ftp.us.debian.org/debian/pool/main/g/gitosis/gitosis_0.2+20080825-14_all.deb
sudo dpkg -i python-support_1.0.2_all.deb
sudo dpkg -i gitosis_0.2+20080825-14_all.deb

Use this at your own risk; your mileage may vary.

Sometimes You Need to Compile It Yourself

I posted an earlier version of this on the Puppet mailing list recently; it seemed worth expanding here.

An Ideal World

In an ideal world, for each piece of Linux software I use, a very recent version would be “in the box” in the distribution package repositories, for every distro and distro release I use. The package versions would be updated promptly, and backported to the most recent N distro releases. This would be done in such a way as to avoid unexpected breakage, offering a combination of original (as of the distro release), bug-fix-only, and all-updates.

We don’t live in such a world.

The Real World

I’ve found that, with at least Debian, Ubuntu, Red Hat, and Mandrake, typically only the most popular packages are prone to prompt updates for new upstream versions. Backports to not-the-current-distro are even more rare, for various good reasons.

Therefore, when adopting something less widely used, especially if I need the same (current) package version for various distro versions, I’m resigned to having to either package it myself, or find someone “out there” offering updated packages.

Example #1: Puppet

As I write this, the current Puppet version is 0.24.8. It contains a lot of bug fixes and enhancements relative to even the earlier 0.24.x versions. It would probably be only a slight stretch to say that in the Puppet community, versions before 0.24.x really aren’t recommended for current use at all. Yet the most recent versions offered in-the-box for the last few releases for Debian / Ubuntu are all old enough to be in that category.

Example #2: udpcast

Udpcast is an extremely useful tool, both for cloning systems en masse, and for totally unrelated uses like the one I describe here; yet the version in the very latest Ubuntu is from 2004, and the same is true for Debian.

Example #3: Zabbix

To get good results with Zabbix, it’s necessary to have approximately the same, approximately current versions, on all machines. The versions in various current and past Ubuntu and Debian releases / backports are not even close.

But Please, Use Your Package System

Please, I ask you… and if you work for me on one of my projects, I require of you… do not take any of this to mean you should ever type “sudo make install”. It’s a nightmare to untangle a system with a mix of packaged and ad hoc compiled code in /usr/bin and friends. Always install using the package system: for a one-off (one machine, ever) install, simply use checkinstall, it takes only an extra minute or two and make it trivial to back the install out later. For a set of production systems. dpkg and RPM are your friends. They won’t bite. Get to know them.

Bar Camp St. Louis, a stealth micro-unconference?

Today I stumbled across the web evidence of Bar Camp St. Louis (Flickr stream, Facebook group) , a software / social networking flavored “unconference”. It occured a few months ago, on Dec. 13th, 2008. I’m not sure I’d have attended, but I am surprised that went below the radar of any of the various user groups / mailing lists I follow.

DRBD on Ubuntu 8.04

A while back I wrote about setting up DRBD on Ubuntu.

It is considerably simpler now: you don’t need to build the module anymore, a reasonably recent version is already in the box. You should still read the full directions at the DRBD web site, but to get it going, you only need to configure it and start it; don’t download anything, don’t compile any modules kernels, etc.

Rather, the module is already there; you could load it manually like this:

modprobe drbd

But you really want the utils package:

apt-get install drbd8-utils

… which sets things up the rest of the way. Simply proceed with the configuration file, /etc/drbd.conf. If you want a nice clean config file, remove all the existing resource sections in the drbd.conf installed by the Ub package, and put in something like so:

resource kylesdrbd {
  protocol      C;

  startup { wfc-timeout 60; degr-wfc-timeout  120; }
  disk { on-io-error detach; }
  syncer {
  }
  on x1.kylecordes.com {
    device      /dev/drbd4;
    disk        /dev/sdb5;
    address     192.168.17.61:7791;
    meta-disk   /dev/sdb1[0];
  }
  on x2.kylecordes.com {
    device      /dev/drbd4;
    disk        /dev/sda5;
    address     192.168.17.62:7791;
    meta-disk   /dev/sda3[0];
  }
}

The hostnames here need to match the full, actual hostnames. I show my example disk configuration, you’ll need to do somethign locally appropriate, based on understanding the DRBD docs.

Also adjust the syncer section:

syncer { rate 40M; # the rate is in BYTES per second }

If there was already a filesystem on the metadata partitions you’re trying to put under DRBD, you may need to clear it out:

dd if=/dev/zero of=/dev/sdb1 bs=1M count=1

Now you’re ready to fire it up; on both machines:

drbdadm create-md mwm drbdadm attach mwm drbdadm connect mwm

# see status:
cat /proc/drbd

You now are ready to make one primary; do this on only one machine of course:

drbdadm -- --overwrite-data-of-peer primary all

drbdadm -- --overwrite-data-of-peer primary kylesdrbd

In my case, I now see a resync starting in the /proc/drbd output.

You don’t need to wait for that to finish; go ahead and create a filesystem on /dev/drbd0.

It’s best to have a dedicated Gigabit-ethernet connection between the nodes; or for busy systems, a pair of bonded GigE. For testing though, running over your existing network is fine.

I found that an adjustment in the inittimeout setting helps to avoid long boot delays, if one of the two systems is down.

Of course I only covered DRBD here; typically in production you’d use it in conjuction with a failover/heartbeat mechanism, so that whatever resource you serve on the DRBD volume (database, NFS, etc.) cuts over to the other machine without intervention; there is plenty to read online about Linux high availability.