Palm needs every developer to extol the awesomeness of this device and the wholesomeness of the company. They need them to lure people away from the iPhone. Sprint needs every subscriber. If they plan on getting them with the Pre, they need some good apps and a reason to move the early adopters — the ones that want to hack in tethering — over from other carriers.

The beginning of the end, I say ….

• Gizmodo: Reality check: iPhone vs Palm Pre launch
• Techcrunch: You call 50,000 Palm Pres Sold a success? Investors don’t think so.
• Boston Globe: Palm Pre good, but it’s no iPhone

Yowsahs.

• Palm releases the Pre at CES in January ’09. No one buys either a Sprint phone or a Palm device for 6 months. Not that’s good for revenue.
• Palm has a rumored 6 month exclusive distribution agreement with Sprint. Then, supposedly, Verizon and AT&T get into the mix. So, current, under-contract Verizon and AT&T customers that might even want the Pre won’t switch because it is coming in 6 months to their current carrier. Whoops.
• Palm’s ridiculous launch date this past Saturday. Seriously, WWDC could lay the biggest egg and still, all the press got there Sunday night to party and haven’t written a single word about Palm Pre since, oh, Saturday afternoon.

So how can Apple really put Palm’s corpse in the ground?

• Steve Jobs comes to WWDC. Just a peek. No keynote. Just a, “hey there”. The faithful will be whipped into such a frenzy that they literally will wipe the Pre off the face of the earth with their crazed chanting and swaying.
• Apple undercuts the $199 w/rebate price with the iPhone, as rumored, at $99. Pow!
• AT&T offers some sweet rate plans that are designed to retain would-be-Pre customers.

Oh well, it’s been a good run! I like the hardware (minus the reported self-mutilation-sharp keyboard). Just don’t trust the company. Me, I’m waiting for the Monday late afternoon lawsuit.

• CrunchGear: Here’s what’s wrong with the Palm Pre
• The New York Times: Sprint and Palm: Don’t Expect a Pre Frenzy

Interesting. I especially like the bit where the chin of the phone actually causes palm pain for some users.

More to come tonight, hopefully.

Palm, Inc. has been on the proverbial corporate respirator for a really, really, long time. We all remember the days when it was just the Pilot 1000 and U.S. Robotics, and they were the only game in town for personal, portable, and usable.

Fast forward through 3Com, licensing of the OS, Handspring, the Palm spinoff, and a raft of Clie’s, Treo’s, Tungsten’s. The invention of Graffiti, the lawsuits around Graffiti, and then the other skirmish v. Microsoft because of the word “Palm”.

Then the acquisition of Handspring, the spinoff of PalmSource, the absorption of Be, the integration as palmOne, and then the rebranding as Palm, Inc.. Whew.

Do you get the feeling that The Powers That Be spent a lot of time on licensing, restructuring, and trying (in vain) to find their way, all the while basically forgetting to work on making cool, usable stuff? Or, really, releasing new product? Oh, the Palm Foleo? Yeah, you get my point. Combine their history of incompetence, and you begin to think, really, has any company needed their yet-to-be-launched product to succeed more than Palm needs the Pre?

So how can they screw this up? The Pre looks to be cool technology, but Palm has taken their stupendous lead in the handheld market from 1996 and turned itself into a washed-up has-been, watching  iPhone, Windows Mobile, Blackberry, and even Android pretty much take their lunch money. I anticipate this to be a flop for Palm, and I expect it to go down in style.

So here it is, in no particular order, the first installment of “Ways in which Palm will mess this all up”:

1. The idiotic launch date.

Palm’s decision to “launch” the Pre (and I say “launch” in quotes because everyone knows everything about this handset and even the Sprint service — there are no surprises here, or even anticipation, really) on the Saturday (huh? weekend?) before the Monday of the industry’s most anticipated launch party, Apple’s WWDC. How can this timing be a good idea? Even if the Pre is the best product in the world — and I mean can slice cheese, do your laundry, brew beer, and get you dates — the press and the blogosphere will have a grand total of about 48 hours to tell us about it. On a weekend. That’s if they had anything new to say about it. Really, it’ll just be bloggers with endless unboxing videos. Everyone else has already seen the pictures, watched the videos, and read the reviews from the professionals. No minds get changed with the “launch”. There won’t be 2-month-long lines outside Sprint stores for the Pre.

Even if WWDC is a huge flop, the press will still be obligated to cover it. All that news (postitive or negative, but really just 227 unboxing videos) about the Pre? Lost below the fold Monday morning. Hell, I’ll take the bet that if WWDC doesn’t announce a single new product idea, even if Apple comes out and shows YouTube videos on the screen for 3 hours as as keynote and doesn’t even get John Mayer to play live, the coverage will be ten times that of the Pre. Sorry, Palm, the Apple PR juggernaut will not be derailed by your Saturday “launch”.

The only logical reason I can understand for the timing is so that Palm has a half-decent excuse when their sales figures are disappointingly low and the “shortages” of Pre devices lasts about 3 hours. My bet? No more shortages, oh, about 11:15AM PST Monday morning. The first article with a quote from a Palm employee blaming the WWDC shadow for lagging Pre interest on about June 19.

They realized that they showed their hands too early to get a stock price bump, and that any wave of enthusiasm has run out. There is no surprise, there is no pent-up demand. There is only the stark reality that this is just another smartphone competing in a ever-crowded segment. No lifestyle upsell like Apple, no suit-and-tie corporate backing like Blackberry or Windows Mobile. Just a decent piece of technology on a languishing carrier (Sprint) without any applications. Just like the others, except without the existing codebase, userbase, and application store. Nope, just the last gasp from a dead company.

So yeah, I’d launch as close to WWDC as possible. “Look, it wasn’t our fault. Who knew that Apple would launch a new generation of iPhone/iTablet/iMac/MacBook? Why don’t you love us? It isn’t our fault. It isn’t our fault.” Somehow, I don’t think that will resonate with shareholders.

2. Palm, Inc. stole some intellectual property for the Pre and will get sued for it on June 8.

I thought this up at a bar with some of my former students. Sounds like a plausible way Palm would get the wind knocked out of their biggest product launch in ages, right? The story goes something like this:

Somewhere in the mess of acquisitions, licensing, and spinoffs, Palm engineers “borrow” some piece of technology for their core webOS without permission. A total D-League move for sure, but hey, these engineers didn’t think they would actually make product launch (see Palm OS Cobalt). And to make matters worse, it’ll be something a bit obvious, and it will be owned by a huge player. Say, like Cisco, Microsoft, or even Apple. It’ll be something core to the operating system, like pinch zooming or how they handle device rotation, and definitely core the experience. Either way, it’ll be a huge blow because Company X will have been sitting on their hands until they decide to knock them out with a lawsuit a couple days after launch.

But, in true Palm fashion, they get the sucker punch first, then the left hook next. The lawsuit will break after the WWDC keynote, and we will realize that Apple will have made a big deal about the partnership with Company X. Oh yeah. This is how it should go down. Hell, Company X should be Apple itself. I can see it already. The WWDC keynote showcases some interaction that Palm touted two days prior, followed by a picture of the granted patent application for Apple. As Jobs would say, “Boom!”

3. The Sprint customer service kills it all.

Not exactly in their hands, but still their doing, Sprint becomes the weakest link. In the best case, Sprint is hit hard by the surge in demand for the Pre. Sprint employees, being Sprint employees, can’t handle the demand and are completely crushed. In-store customers get bogged down in up-sells and spend 2 hours trying to activate their phones. Actual lines form at stores, but not because the phones are in such demand. Combine this with the incompetent online ordering system and the unique ability of Sprint to get your plan completely wrong even with a form submitted via the Internet, we start to see picture of a horrible first-time-buyer experience. Delayed orders, data plans not attached to rate plans, botched number port-ins. Egads. You can’t trust Sprint to handle their existing customers. If they get a bunch in one morning, God help them.

And that’s the best case.

… more to come.

Got some ideas? Leave ‘em in the comments.

• Cupcake (v1.5) for Android Developer Phone is official from HTC
• Vodafone Spain is launching the HTC Magic today, apparently
• Italy’s TIM is getting the HTC Magic
• Samsung officially announces the I7500 Android phone in Korea

Awesome. If you haven’t played with the 1.5 release (Cupcake), I would definitely do it.

Forthcoming from Vodafone in a month or so is the Vodafone Magic (HTC Sapphire). It will come standard with a new build of the Android platform, dubbed “cupcake”. Some lovely person on xda-developers has ported the firmware and radio images to work with rooted G1′s (links below). This is so good. There are two versions floating around. The “G” version is based on a Google build, and an “H” version sourced from HTC normally destined for the Chunghwa phone. If you’re going to do this, go full-boat and get the HTC-branded, and more fully-featured “H” version.

You can search the Internet for lots of side-by-side comparisons of the Google and HTC builds, and you can find lots of stuff about the cupcake branch. But all you really need to know is that the HTC build comes out-of-the-box with push notifications for all Google services (Mail/Calendar/Contacts/Talk), as well as Exchange (Mail/Calendar/Contacts). HTC just put this phone on the “enterprise” map. After a simple setup process and a few minutes of playing with it, the Exchange synchronization seems flawless. Push notifications are instant, everything is configurable like you would expect on a Windows Mobile platform. Since Android uses a platform dialer and contacts manager, you can select both which contacts get synchronized (Google only, Exchange only, both, etc.), and/or show only select groupings. Same goes for the calendar. So awesome, and so right.

Cupcake will make Android my next phone without a doubt. Just as soon as they release a CDMA EV-DO Rev. A model for the Sprint network, because you can pry my Sprint SERO plan from my cold, dead, hands.

For the curious, the Exchange client identifies as:

Device ID: HTCAnd7e7413d6
User Agent: Android-EAS/0.1

Links:

• Original xda-developers thread by haykuro
• haykuro’s blog
• Google Code project with all the firmware and instructions

Try sending yourself an email with the plus sign, “+” in the subject. Outlook can see it. Webmail can see it, but Entourage has no friggin’ idea it is there. The receipt of the mail triggers the sync of the inbox, but nothing shows up! What the hell?

Now, to find where the heck the bug submission button is…

Now, the GOF is a Nortel piece that uses a custom hash function for the username running and standards-based IPSec VPN. Boo. That means it won’t work with any third-party VPN client. You have to use the Contivity piece of garbage. Bonus that this piece of garbage is written by Apani, and is now no longer actively supported. Double ugh. So here is what I need:

• VPN access to the work network
• Tunneled through SSH
• Ability to redirect DNS lookups through the VPN
• Free, as in speech

What you’ll need to do this:

• Root on a linux server inside the firewall
• Mac on the outside

There, not so hard? Thankfully, the Intarwebs and a little hacking last night delivered the goods. In short, I used OpenVPN, a few scripts, and a little luck. Here’s how.

Server

1. I used Ubuntu Dapper inside a Xen virtual machine. Worked great.
2. apt-get install openvpn openssl bridge-utils
3. cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn
4. Follow the directions for generating keys at the OpenVPN HOWTO
5. Copy the keys to the right places, as from the above HOWTO. I put my keys in /etc/openvpn/keys
6. Use the following configuration file for your server. This assumes an ethernet bridge will be built (later) and that you have a DHCP server somewhere on the LAN to give out IP addresses to VPN clients
   
proto tcp-server
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
mode server
tls-server
client-to-client
keepalive 10 120
cipher BF-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
7. Create the ethernet bridge Debian-style by adding the following lines to your /etc/network/interfaces:
   
auto br0
iface br0 inet dhcp
pre-up openvpn --mktun --dev tap0
bridge_ports eth0 tap0

8. Restart network with /etc/init.d/network stop and /etc/init.d/network start
9. Now you should still have internet connectivity, and eth0 and a br0 bridge

Client

1. Get and install OpenVPN 2.x. I used Macports, so I just fired up ports like: sudo port install openvpn2
2. Grab and install the tun/tap driver for Mac OS X
3. Reboot, or force install the kernel extensions
4. Make sure you have the client encryption keys from above, and use the following client configuration:
   client
dev tap
proto tcp-client
remote localhost
tls-client
ca /opt/local/etc/openvpn/keys/ca.crt
cert /opt/local/etc/openvpn/keys/mchang.crt
key /opt/local/etc/openvpn/keys/mchang.key
cipher BF-CBC
comp-lzo
nobind
persist-key
persist-tun
up /opt/local/etc/openvpn/tap-up-down.sh
down /opt/local/etc/openvpn/tap-up-down.sh
verb 3

5. Grab the openvpn-tap-up-down.sh script from the bottom half of this mailing list posting, or download it right here: tap-up-down.sh
6. Install that tap-up-down.sh in /opt/local/etc/openvpn and chmod +x it so it can be executed

Fire it up

Now we’re ready to start this thing up, over an SSH tunnel, kind of like describe in this post.

1. Fire up your ssh, tunneling the OpenVPN port like
   ssh -L 1194:vpn.your.domain.com:1194 ssh-gateway.your.company.com
2. Where ssh-gateway.your.company.com is your ssh gateway, and vpn.your.domain.com specifies the tunnel endpoint at the VPN server you have just set up.
3. Turn on OpenVPN on the server like
   openvpn --conf /etc/openvpn/bridge.conf
4. Turn on OpenVPN on the client like
   sudo openvpn2 --config /opt/local/etc/openvpn/client.conf
5. You should see, on both sides, OpenVPN authenticating and then starting up.

Now, you should be able to ping any machine on the remote subnet. I wanted to be able to get to anything on the internal network through the VPN, so I manually added a route to all of the internal network (10.0.0.0/8) through the VPN server’s default gateway. Like this:

route add 10.0.0.0/8 10.49.27.1

Of course, substitue the IP of the VPN server’s gateway to the rest of the network for 10.49.27.1. That, combined with the handy script from Ben Low, allows all DNS lookups for the internal network to go to the internal DNS servers, routed through the VPN.

Some notes:

1. On the server side, everything is pretty much normal. I can’t seem to use the “push redirect-gateway” through this system, as a) either the OS X port of OpenVPN doesn’t support it (unlikely), or b) the gateway information is a little borked as it is going over an SSH tunnel. Either way, I just manually add the route to the default gateway.
2. For some reason, the tap0 driver does not go into DHCP mode by default. You have to force it using the ipconfig program, which is done for you in the tap-up-down.sh script.
3. On the client side, Mac OS X has a very complex name resolution service. Very cool if you get under the hood, as seen in these two threads on the Apple developer mailing list. The end result is that when you get the DHCP lease from the internal LAN DHCP server, the tap0 device gets some service keys that record the DNS servers pushed from the LAN DHCP server. After the tap0 driver comes up through OpenVPN, you can see this by running scutil from the command line, and executing
   get State:/Network/Service/DHCP-tap0
d.show
4. Now, OS X needs to have a SupplmentalMatchDomains key associated with these DNS entries before it will actually consult them as part of the name resolution service. The script does that for you. You can see its effects after the VPN starts up by running scutil --dns

There you go. Now poke holes in your own Great Corporate Firewall!