I am So Old

Two things happened which remind me that I am really old when you think about how fast things are changing. Many have noted that most kids today don't have any idea about vinyl records, even though the needle-across-the-record sound effect is so common in TV shows for the young-uns. I don't think my kids would even recognize an LP if they saw it. For that matter, I realize that by calling it "vinyl" that puts me into a particular generation. My mom would probably point out that I wouldn't recognize a lacquer phonograph disc if I saw it...

I digress. It's telephones that are really really different. We are seriously spoiled by cell phones now, and most kids have no concept of having to stop and find a pay phone (that's a good thing-- I certainly don't miss that particular annoyance). I'll bet you cannot find a 15-year old who can even recognize a pay phone, much less know how to use one. How about phone booths? What would Superman do today? Head for Starbucks I guess.

Alexei, my 10.9 year old, asked me yesterday, "What is that thing on the phone that people put their finger in and turn it in a circle?" Haw! I told him the technical details are too much to go into (I look forward to the day when I can explain to him in detail why that particular user interface was chosen) but I said that is how people used to dial telephones. Weird, huh? Then I realized that we still use the word dial, but I havent found the dial on my cell phone yet. In fact, I said, all telephones used to be like that.

I did not go on to say that those phones HAD to be connected to the wall by a wire. Hey people-my-age, remember when you had to get the really long coily line to the handset so you could at least walk around the kitchen while on the phone? When I was in college, my girlfriend and I had a phone which had a really long cord to the wall, and a really long cord between the handset and the base. The long cord to the wall was motly transparent, so there were spare loops of it always getting hooked on someone's foot, which would spectacularly rip the phone off of whatever shelf it was resting on. This led us to label the phone the "Attack Phone" because it would ambush you when you walked by.


A few minutes ago, I heard a busy signal in a movie. Here's another thing that kids won't understand. Voice mail and call waiting is pervasive, so there is essentially no time at which a kid will hear a busy signal and know what that means. What, we are not busy anymore? For that matter, younger kids use cell phones so much, and land lines less and less, the whole notion of a dial tone is unknown. What other sounds of early telephony are already lost?

Helio Ocean Review

I was a late adopter to cell phones in general, and I still don't use mine very much. But when it works, it's amazing. We've all forgotten just how amazing it is to have a telephone with you at the park and call a friend, or to call in a smoothie order from the freeway. Portable phone, good. How about portable internet on a 1-inch screen? Ugh, no. The whole WAP internet thing was a joke to me. In a pinch, accessing the internet on a vanilla cell phone does work, but it's sort of like eating a bowl of cereal with tweezers.

With the advent of "smart phones" or "internet enabled phones" or whatever the current term is, I became curious, but still skeptical. Sure, you can get a BlackBerry in color, but the internet still sucks and is virtually unusable. Apple's device finally demonstrated that it's possible to have a useful experience on a tiny machine. Good for them, and good for us because the pressure is really on all the other vendors to provide an internet experience that is not completely compromised. I would have purchased an iPhone but Apple just had to do that deal with ATT-- my experience with their service in my area was so bad that a hard association with ATT was a deal killer. No matter how nice the internet, if I cannot reliably use the thing as a phone, forget it.

I bought a Helio Ocean to see if it would work for me. I had seen a demo of it, and read a nice piece about it and its design in Technology Review (http://www.technologyreview.com, registration required, but worth it). What follows is my take on this device after a couple of weeks of use. Short summary: excellent value, very good software, worthwhile machine.

The Helio people giddily point out that theirs is the first dual-slide phone out there-- if you slide it along one axis, it's like a phone, and slide the other way, it's a thumb-qwerty keyboard. I suppose this is a differentiator, but, for me, it's just more moving parts to break. You can read all the official features at the Helio web site: http://www.helio.com.

Internet: good, very usable. This is because the iPhone with its larger screen and touchscreen interface is just flat better. The Ocean is definitely the next best thing. There is a stock browser that comes with the phone, and Opera mini is available for the phone as well (also free) and works well. The screen is large enough to view as HTML but of course you have to scroll around a lot. One sensible feature is that the machine is set up to assume that if you open the keyboard and start typing something, then your goal is to perform an internet search. So by typing something in and hitting the "go" button, you get a tab-summarized search of Yahoo!, Google, Wikipedia, Amazon, etc. Sensible and useful.

Music/Video Player: very good. The stock Ocean has a few hundred megabytes of available storage to which you can easily copy mp3 files. I also added a 2G microSD card ($35! cheap!) so can carry several CDs worth of music around with me. The audio quality on playback is just fine, but (as expected) my Creative Labs' Zen is a bit better. I have been using the Ocean to carry around Jon Udell's podcasts and it's perfect for that. You can view video from YouTube on it, but the quality is not great. YouTube video quality is not fabulous to begin with, and once you down-level it for mobile use, it's even worse. But it works, and that alone is pretty amazing. Because YouTube is an endless source of bizarre entertainment, if your smartphone's main purpose is "interstitial time killer" then this feature is huge.

User Interface: very good. Because it's not a touch screen, there are physical buttons involved, and this means that you have to do lots of scrolling with what amounts to keyboard equivalents on a cell phone, rather than using the mouse (or your finger) to point and click. Both the Opera Mini browser and the Helio browser do a decent job of this click-click-click-select thing. Happily, there are several places where the "soft" buttons that surround the phone do the "right" thing; i.e., the thing you are most likely to do is associated with a button which is just clicked with a thumb. Another thing which the designers executed well was adjustment to the phone's orientation. Recall that this phone acts like a cell phone when you slide it longways, and more like a BlackBerry when you slide it out sideways. All the applications on this device do the right thing when you switch orientation, even down to the buttons. E.g., if the lower right button is "go" in landscape mode, if I flip it the other way, the lower right button is still "go" even though it's now a different physical button. Make sense? Probably not-- so suffice to say the Principle of Least Surprise is normally in effect on this phone. Well done.

Phone: excellent. Oh yeah, you can also use it as a telephone! Works great, clear sound, good microphone, tolerable speakerphone. Easy to redial, return calls, call from history, all that works great. The stock ringtones are uniformly obnoxious to the extent that you are compelled to go purchase something different, which I resent. Therefore, my phone is on buzz most of the time. Someday I will get a different ringtone. But even if I get around to downloading one, I simply don't want some top-40 song playing when the phone rings, or some cheesy 8-bit synth tune. Maybe if I got some Frank Zappa, or maybe the sound of a stomach rumbling...

Service Plan: very good. It's simple like they all can and should be. Helio charges a competitive flat rate for the service I get which includes the internet, text messaging, pictures, etc, and there are more-inclusive plans for fanatical users, and good "family plans". Alas, it's a 2-year deal, which I don't like, but oh well. Signing up is really simple, and you can do most of it online. I didn't have a great experience activating the phone because the overseas guy who helped me was on (I think) his first day and barely knew what he was doing. To his credit, he tried really hard and was fun to deal with-- youthful exuberance and all that. I had to call back to get my phone activated, because in fact he hadn't actually turned it on.

Camera: very good. Why the heck do I want to have a camera in my telephone? How about a cheese grater built into that gas grill? I admit, I am sufficiently old to have taken a long time to understand or appreciate the idea of having a camera on a phone. The gen-Y group got it right away because they all have phones with them all the time. So of course, when you have a camera, and you are with friends, it's a perfect match. And it's just plain nice to have a simple camera with you all the time, which you do when it's stuck to your phone. The camera on the Ocean is really very good, and the UI is sensible. Plus, it has a video camera which is nicely integrated with the YouTube application so you can capture a decent quality video and post it straight away. The newly-released YouTube viewing application has a really nice ajax-y feel to it which I found to be quite usable. This particular application on the Helio convinced me that the platform is capable of supporting nice-looking and usable applications on the Helio platform (which is SK Telecom, for those of you interested in that sort of thing).

Reliability: good. I can only give this a "good" rating because I have seen the phone crash completely due an application error. Of course there are some bugs, which I, as an early adopter, happily accept. It reboots quickly (15-20 seconds). I subscribe to Jerry Pournelle's observation that "any error rate large enough to measure is too high" for this sort of thing. An app can crash, but it shouldn't kill the OS. We as consumers need to insist on OS stability even with nutty applications.

Battery: good. Naturally, if you use the internet and camera a lot, the battery goes down relatively quickly if you judge it as a cell phone. The phone charges on USB or on the dedicated charger which comes in the box, and the battery life is great if you are only using the telephone. I have seen the charge plummet though while using the camera-- where it goes from apparently 80% to turning itself off in the course of 5 minutes or so. It doesn't normally do that with the camera, so I am thinking something went off in the weeds that day. I am anxiously watching for that to happen again.

Custom App Dev: not good. Because I am a developer, one of my first questions is "how can I create an application for this thing?". I dug deep on the internet trying to find an answer to this-- I know that the platform is SK Telecom, so surely there is a dev community out there, and a way to put apps on the system. Well, no. An email to the Helio people requesting access to their SDK and documentation said, in effect, "pitch your idea and business plan first, and we'll decide if you can have access the docs." Sorry, this is just plain stupid. Not that I have a million great ideas, but you have to understand the platform's capabilities and limitations to completely form a vision of what an application can do. I guess I'll just have to make something up and send it in, or, more likely, just target the iPhone.

GPS: The phone has GPS on it, but I am not enough of a GPS geek to know what chipset is being used, or what resolution it provides. What I have seen is the Google maps application on which the phone overlays your current position. It's a small thing, but a natural and extremely useful combination of features. For example, you can put in an address you want to get to and the phone knows where you are. Not helpful when I am at my house, but huge when you are lost in the urban jungle. Garmin has an app that runs on the Ocean which provides audio turn-by-turn directions, so for some extra bucks, you can add the features of a full-featured standalone GPS unit to your telephone. Very cool.

All in all, I like this thing. There are lots of features on this phone which I may never use and didn't mention, but be sure to visit the Helio site for a complete rundown. I use the telephone while out and about, check my Yahoo! mail with it, send text messages with two thumbs like never before, and have even done some internet RSS reading on the bus with it. There are many cool and useful features-- even for my demographic. Now I can finally accept that it's possible to access the internet from a super-portable device in a useful way.

PowerShell V2.0 Background Processes: Tiny Overview

Just Now?

For many years I have hoped for some construct in windows that works as well as in *nix to put long running processes in the background. There are ways to hack it in Windows, but all of them seem to have issues. Essentially, if you are running a long-running application from a console with Windows, no matter how you slice it, you are going to have a console window somewhere. Or you could make your operation a proper first-class Windows service, but that's hardly helpful for a long-running WSH script. Happily, we now have backgrounding in the PowerShell V2.0 along with lots of other new features. What follows is a slice of how background jobs known as PSJobs in PowerShell behave.

Typical of PowerShell, the implementers didn't just copy what was done in *nix, they took the opportunity to make things better, or at least more complicated. With *nix (Trademarknix?), capturing output from background jobs was sort of messy with that 2>&1 approach to redirect stdout and stderr, and then you still have to redirect that output somewhere. Even when you manage to track all the output of a process, once jobs are put in background there isn't much else you can do except kill them.

Consistent with the PowerShell Way, creating a background process actually returns a handle to an object with methods and properties. This handle also goes into a table that can be directly inspected and manipulated or as part of a pipeline. This is a distinct improvement over the traditional *nix-style where the job is placed into an opaque system process table which is more complicated to access. Of course in *nix you can get the process ID of a running process by parsing the output of the 'ps' command, but that metadata on the process doesn't get you much. PowerShell does it better. Read on for a simple example.

There is a family of PSJob cmdlets, shown here for fun:

• Start-PSJob
• Get-PSJob
• Receive-PSJob
• Stop-PSJob
• Wait-PSJob
• Remove-PSJob

This post will focus on Start-, Get-, and Receive-PSJob.

Basic Tour

What happens when you use this feature? We have to have some cmdlet to run in the background for demonstration purposes, and I picked get-service as an example even though it doesn't really run very long. It's a useful example because it returns somewhat familiar output.

But First

The PSJob infrastructure depends on the new PowerShell remoting feature, and, for that, you need WinRM installed and running on your system. You probably already have WinRM installed, but it may not be running so you may have to start it up by visiting the services controller (services.msc) or use start-service in PowerShell. If you don't even have WinRM, you can download it here: http://www.microsoft.com/downloads/details.aspx?FamilyId=845289CA-16CC-4C73-8934-DD46B5ED1D33&displaylang=en . And of course you need to have uninstalled any PowerShell 1x and installed the PowerShell 2.0 CTP bits. Note that PowerShell doesn't show up in XP on the add/remove programs list unless you have "show updates" checked.

If the remote management service is running, you likely will also need to run a WinRM setup script delivered as part of the PowerShell 2.0 CTP. This is in $pshome and you can run it from a PowerShell prompt this way:
PS C:\> & $pshome\Configure-wsman.ps1

(mysterious output)

Onward

Do this in a PowerShell prompt:

PS C:\> start-psjob -command "get-service"

You should wind up with something like this, your numbers will of course be different, and your font, and the spacing, and your time of day, but do I really need to tell you that?

PS C:\> start-psjob -command "get-service"

SessionId Name State HasMoreData Command
--------- ---- ----- ----------- -------
26 Running True get-service

So what happened to the output of the get-service command? It gets pulled into the PSJob identified by Session Id in the table for later retrieval. Note that the State is reported as running. The Start-PSJob returns to you the handle to the job you just launched. This handle is also stored in the PSJob internal table, which is accessible in the session using Get-PSJob.

PS C:\> get-psjob
SessionId Name State HasMoreData Command
--------- ---- ----- ----------- -------
1 Failed False get-service
3 Failed False get-process
5 Failed False get-process

...many other failed attempts because I had neglected to actually turn on the WinRM service silly me...

24 Completed False get-service
26 Completed True get-service

You can get the handle to the job either by grabbing it at launch time, like this:
PS C:\> $svc_job = start-psjob -command "get-service"
PS C:\> $svc_job.SessionId
30

Or by using the -SessionID argument to the get-psjob cmdlet:
PS C:\> $svc_job2 = Get-Psjob -SessionId
30
PS C:\> $svc_job2
SessionId Name State HasMoreData Command
--------- ---- ----- ----------- -------
30 Completed True get-service

However you arrive at the handle, you have what you need to check the running state, the command issued, and a HasMoreData flag which is useful to see if the handle's output buffer has been drained. All this is good to know, but where did the output go?

To locate the output for this run, use the Receive-PSJob cmdlet. This cmdlet parses the handle to the job and returns the output and error result of the execution. In the example below, it's just returned to the console via default ToString behaviors, but you would normally capture the Receive-PSJob output and do Important Work with it. Be aware that this is, by default, a "destructive" read in that it drains the buffers that it reads. (There is a -keep parameter for Receive-PSJob you can use if you want to read the buffers multiple times. For that matter, you can inspect and read from the member directly like this: $svc_job.ChildJobs[0].Output).

It's just a little disconcerting at first glance:

PS C:\> $svc_job receive-psjob

...
Running winmgmt Windows Management Instrumentation
Running WinRM Windows Remote Management (WS-Manag...
Stopped WLSetupSvc Windows Live Setup Service
Stopped WmdmPmSN Portable Media Serial Number Service
Stopped Wmi Windows Management Instrumentation...
Stopped WmiApSrv WMI Performance Adapter
Stopped WMPNetworkSvc Windows Media Player Network Sharin...
Stopped wscsvc Security Center
Running wuauserv Automatic Updates
Running WudfSvc Windows Driver Foundation - User-mo...
Running WZCSVC Wireless Zero Configuration
Stopped xmlprov Network Provisioning Service

And then running the same Receive-PSJob on the same handle:
PS C:\> $svc_job receive-psjob
PS C:\>

No output the second time we call it, because the first invocation already drained that output buffer. Note also that if you inspect the $svc_job handle after the Receive-PSJob call, $svc_job.HasMoreData is False.

As I mentioned earlier, unless you are a one-liner alpha-geek in PowerShell, you'll probably use (like me) constructs like this inside of short scripts:

$svc_listing = Receive-PSJob $svc_job

And then process the resulting array to locate something by service name to checks its state.
Of course, the practical application of using Receive-PSJob will depend on the output of the operation being backgrounded. The main goal here is to show the basic recipe to background a process, and what to do with the result. I haven't looked closely (yet) at how the results from backgrounded cmdlets are serialized, except to see that they are serialized, and that it warrants more investigation. In the example of get-services, it appears that the serialized version of a service handle is available as opposed to a live reference to a service-- you wouldn't (for example) be able to invoke a Start() on a service after retrieving it with Receive-PSJob.

That's one quick tour of one small part of the process backgrounding in PowerShell v2.0. I am very happy to see this feature, and it looks like they did a nice job with it. I am also very happy about the remoting feature, which I'll look at another time.