TSclientX: replace Microsoft's Remote Desktop Client with one made for OS X

I use Microsoft's Remote Desktop Client to control XP machines at home and work and to connect to Windows Terminal Servers (Win 2003). The terminal services interactions in particular are awesome, there's nothing comparable in the OS X world. It's my top complaint about OS X -- that Apple has never even tried to match Microsoft's six-plus year old remote control technology. 

Microsoft's Remote Desktop Client works very, very well under XP. They even made a client for OS X, but they stopped updating it a while ago. It's increasingly flaky, though I use it with some success even under 10.4.10 on a MacTel. I doubt, however, that it will work at all under 10.5 (BTW, I don't expect 10.5 until the spring of 2008 -- projects that big don't slip by only a few months, if it ships in October 2007 it will be dangerous).

So I'm very interested in TSclientX - An alternative RDP Client for Mac OS X. Runs native on Intel. Alas, it requires X11 ..

TSclientX is a Windows Terminal Services client for Mac OS X.  It appears to be a regular Mac OS application but is in fact an assembly of free software working in concert to provide similar (better?)  functionality to the official Remote Desktop Connection from Microsoft. Additionally, there is a nice tidy VNC Viewer built right in as well.

What makes TSclientX interesting compared to other Mac RDP Clients?

- SeamlessRDP is brought to you by Cendio's SeamlessRDP component.   It was originally introduced in rdesktop 1.5 and just simply rocks...

- Stability and speed on Intel Macs (and PowerPC Macs for that matter)   has been found by many to be superior compared to the official  Mac RDP client.

The most interesting ingredients are:

rdesktop 1.5 - http://www.rdesktop.org
An open source client for Windows NT Terminal Server and Windows 2000/2003 Terminal Services

tsclient 0.148  - http://www.gnomepro.com/tsclient A frontend for rdesktop and other remote desktop tools

VNC Viewer 4.1.2 - http://realvnc.com Virtual Network Computing

libao 0.86 - http://www.xiph.org/ao A cross platform audio library with CoreAudio support.

The GUI uses an optimized GTK+ build, specifically compiled for TSclientX.  Like most Unix-derived software on the Mac, Apple's X11 is required...

Skim for OS X: From Klein to DeLong to me

Ezra Klein likes Skim. I can see why. I downloaded and installed the compact open source application, and even at version 0.51 it's sweet.

I'm an Acrobat guru -- but I'm not a fan. Adobe is not a great software house on XP, and they're truly weak on OS X. They ignore basic OS rules (such as not running as an admin user) and their application update process is profoundly broken. Let's not talk about their browser integration ...

So I know Acrobat Pro extremely well, including the esoteric bits, but I've avoided both the Pro app and the Reader on OS X. I use Preview, a suprisingly powerful application that's a bit short of PDF oomph. Skim adds real notes (not the weird image overlays Preview sort-of provides) and some nice PDF browsing capabilities -- and we're only at 0.51.

Skim looks very promising.

Blogger: Replacement for BlogThis!

I've had quite bad luck lately with the Blooger BlogThis! bookmarklet. It simply fails to open much of the time with both Firefox and Camino. On the other hand the Google toolbar for Firefox "Send To Blogger" function has been working quite well, and of course on the XP platform there's Microsoft's unrivalled "Live Writer" for both IE and Firefox.

Alas, Camino and Safari are left out in the cold, though the BlogThis! bookmarklet seems to work best when I try it with Camino.

Send To Blogger is no panacea though. There's still no category/tag support.

LiOn battery care: it's the heat

Apple has a page up on maximizing iPhone battery life. Some of its universally applicable to all portable devices, others apply to all iPods (see also). The list below includes the web site info, and some of my own superstitions. The item new to me is bolded ...

• Heat. LiOn batteries are damaged by heat. (I don't know if extreme cold damages the battery or simply transiently reduces output.) Keep your iPod, iPhone or laptop cool, especially when charging. Temps over 95C will reduce lifespan, so avoid leaving it in car in the summer. (A LiOn battery that's very hot during charging may be malfunctioning, as in pre-explosive. Don't wait for it combust, get it replaced.)
  
• Use the battery at least monthly. LiOn batteries don't like storage, they age even if they are never used, though this effect is less severe than it once was. If you buy a device that's been on-the-shelf for a year you should expect inferior battery performance.
  
• Run the charge from 100% to about 15-20% and recharge. (I've read this elsewhere and it gets periodically repeated. Others say there's no real problem with frequent "top off" charges except that the "battery life prediction" becomes less accurate.) A full discharge every 1-2 months will make the battery indicator more accurate. LiOn batteries age faster if they're totally drained repeatedly.
  
• Turn off bluetooth, 802.11, etc unless you need it.
• EQ settings: "Adding EQs to playback uses more of your processor, since they aren’t encoded in the song. Turn EQ off if you don’t use it. If, however, you’ve added EQ to tracks in iTunes, you’ll need to set EQ to “flat” in order to have the effect of “off,” because iPhone keeps your iTunes settings intact. Go to Settings > iPod > EQ."
  

Google Apps: An evidence-based impression

I've done enough with Google Apps, including some tech blog and notes comments, that I can provide some experienced, nay, bloodied, opinions. A short opinion, because I need to get to sleep.

1. Google Apps are vastly easier to work with if you get your domain and application set through Google (eNom) rather than trying to convert an existing site.
2. You can create and share a document, but that doesn't mean anyone else in your domain can see it. You have to send an email for them to open it, I think then it stays in their document list.
   
3. The services are very loosely "integrated". There's not even a common "start page" link. You move from service to service. Blogger is sort of integrated through the esoteric and obscure "blogger custom domain" feature -- but Blogger doesn't show up in the service list. There's no maps integration.
4. Google's Page Creator and file sharing functions are abysmal. The Page Creator is buggy.
   
5. If you want someone to be able to edit a web page they need to be a full administrator. There are only three privilege levels: administrator, user and outsider.
6. The Calendaring integration is clumsy. You can add a "Calendar" to the "start" page, but it's only a user's calendar. You can't add the shared organizational calendar or any other calendar to the start page. Calendar discovery is obscure.
   
7. Speaking of widgets, there's an lot of junk in the widget collections Google offers. Google doesn't tell us which are written by their people, and which are marketing efforts.
8. There are are bugs everywhere. Did I mention bugs? Also lots of missing functionality.

On the upside, it's free and the deal for non-profits is particularly good. On the downside it's very raw.

Aperture launchus interruptus due to Shuffle dismountus interruptus?

Most of the many bugs I run into with OS X involve the combination of managed users (less than standard user privileges), fast user switching, and devices "owned" by a single user (try switching users while an iPod is associated with a user).

I wonder if this bug falls into that category. I'd updated QuickTime and iTunes and restarted. Everything seemed well, but Aperture wouldn't launch fully. It displayed the splash screen and hung -- as though it was waiting for something. No SPOD, no spinning wheel, nothing.

I tried a few times and decided to restart. My iMac then hung on shut down, with the "spinning radial lines" effect. I left to do a few things, and 20 minutes later it was still "spining". Then I noticed the iPod shuffle light was blinking yellow. I pulled the shuffle from its cradle and the system shut down immediately. On reboot, with the Shuffle removed, Aperture opened normally.

Presumably on startup Aperture is polling disks, and the Shuffle was in an odd half-mounted state (OS X is prone to dismountus interruptus).

Something worth remembering ...

Google Apps: Configuration for a non-Google managed domain

I now have four Google App/Domain pairs and I've created a fifth Google App for Minnesota Special Hockey (at the moment the latter is down for the migration). I've also suffered through more-or-less migrating several blogs to "custom domains". Even if I ignored recent Gooflops at Gmail and Blogger my experience with Google Apps would confirm Google has way too many partially finished products. Here's some help.

If you create a Google App and register a domain (via eNom, Google isn't a registrar (!)) it's not too bad, though the documentation is scant. If you have an existing domain you want to migrate into the Google Apps suite ... well, prepare to gnaw a limb off. Unless, of course, you read this first, in which case you'll probably decide this is ridiculously complex and do something else.

Here's the secret sauce, hidden away in the help file, I found it because I knew to search help with the string "ghs.google.com".

1. Sign up for your free Google Apps. Non-profits like MN Special Hockey can start out with the regular freebie and then easily upgrade for more free support and services.
2. Now you need to validate your ownership. You can either do this with a CNAME record or you can create a file in the root of your domain that Google will look for. I prefer the file trick since CNAMEs can be treacherous. The Google page for validation will tell you what to do. (See [1] below for a bug in Google's directions.)
   
3. Change your CNAME records (these are simple redirects) to both validate your ownership (if you choose the CNAME validation) and setup your custom URLs for your content at the same time. [2]
   For example (using kateva.org, the domain that hosts this blog), create these CNAME entries all with a relationship to ghs.google.com
   news.kateva.org (for your blogger blogs, I prefer this to blog.kateva.org)
   www.kateva.org
   start.kateva.org (this is the Google Apps "desktop" page)
   calendar.kateva.org
   docs.kateva.org
   mail.kateva.org
4. Google help tells you to do use a "CNAME Lookup" service to test the CNAMEs, but when I followed their advice to "Google" for a service I found nothing. Dumb. Until you validate you can't do anything. Once you validate you can use Google App services at Google URLs.
5. Wait until you're validated, then login to your Google App (https://www.google.com/a/cpanel/kavteva.org for example) and change to the custom URLs that match the above. A bug in Google's "start" page means it always displays the non-custom URL but users can reach it via the custom URL.
6. Now go to blogger and change your blog to the custom domain of blog.kateva.org (for example)
7. If you want the email to work, you have get your ISP to change MX records: "Mail Exchange (MX) records control how incoming email is routed for your domain. Before Google can host your email, you'll need to change these MX records to point to our servers." Until then users get fairly useless generic emails.
   

[1] I attempted to validate using the old "upload file" trick, but Google's documentation of this was nonsensical. Here's exactly what they wrote (changing the secret token):

"Create a HTML verification file named googlehostedservice.html , copy the text specified below into it, and upload it to http://mnspecialhockey.org/ . googledwkgf4845250

Here's what they meant:

1. Create googlehostedservice.html
2. Put the text "googledwkgf4845250" in the file googlehostedservice.html
3. Upload googlehostedservice.html to http://mnspecialhockey.org/

[2] Some registrars let you change CNAMES yourself (yay!) others (boo, hiss) make you write them an email.

Update 7/21/07: I'm still working through this, when I'm done I'll revise this entire post. A few things to note:

1. When you're trying to integrate a pre-existing domain and hosting arrangement with Google Apps you really want direct control over you CNAME redirects. It's a pain to do this otherwise.
2. If you have a pre-existing hosting arrangement your main decision is whether to keep the original web page and file hosting or switch to Google Apps (very weak) web page designer(Google Page Creator) and file server. If the former you want to keep your domain name under the control of your host and keep a CNAME redirect of www.kateva.org (for example) to the domain name. If the latter you probably need to give up the hosting arrangement entirely and plan to recreate all web pages in Google Page Creator (impractical for any but the simplest sites). The case of mnspecialhockey.org is unusual in that we will want to move the web hosting to Google Page Creator because we need something very simple that anyone can maintain.
3. You may need to restart your router to see some of the CNAME changes. I suspect my router was caching old IP addresses, I didn't see the changes until I restarted it. Might have been coincidental.
4. There's a bug in the Google Apps "start" page. Even if you change to a custom URL and create a CNAME redirect, it still publishes to the original "partner" URL and the custom URL resolves to the "partner" URL. I thought this was a Lunarpages error, but I see the same behavior with Google/eNom managed pages.

Update 7/23/07: I've got most of the configuration working, and now I'm implementing workarounds for the one residual intractable problem -- there's no simple way to have mnspecialhockey.org redirect to www.mnspecialhockey.org. It always directs to the lunarpages "subdomain" IP address. I can redirect from index.html on that machine of course, but that doesn't help with other page requests.

Lunarpages recommended URL rewriting using my /public_html/mnspecialhockey/.htaccess file:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^mnspecialhockey.org [NC]
RewriteRule ^(.*)$ http://www.mnspecialhockey.org/$1 [L,R=301]

I'm not positive Google approves of url rewriting, but this example is fairly benign. I reviewed Matt Cutts writings on the topic and I didn't see an obvious red flag.

Update 7/24/07: The URL rewrite seems to work, though the original one I was sent had an error in it (above is corrected). Lunarpages, to their credit, quickly adjusted the MX records so the email now works.

Update 8/31/08: Things were far simpler when I switched from Lunarpages to DreamHost in August 2008. I also have a more detailed explanation of how things work.