HP-UX: a fading star

I have to admit HP-UX is growing on me. It’s prevalent in medical environments, primarily in imaging applications like MRI. So maybe it’s no accident that the 60-pound workstations are called the Visualize series: they come with serious DVI video cards, run Fast SCSI for their drives, run a tightly-integrated 64-bit Unix on HP’s PA-RISC 64-bit processors, and frequently come out-of-the-box with 16 GB of RAM. Yes, that’s gigabytes.

They also commonly run CDE, the Common Desktop Environment shared across several Unix flavors, which is a study in blandness. Yet dig into the GUI administration panel called SAM, and you’ll also find virtualization and clustering built right in, ready to fire up. Granted, you can only virtualize HP-UX hosts on an HP-UX host, unlike the virtualization we expect on the i386 platform: any guest on any host. But for server or high-end applications, this kind of virtualization (also used in Solaris, and called “partitioning” on mainframes) is ideal.

I’m sorry I’ve arrived at the party late. The PA-RISC processor is basically a goner, dropped by HP years ago, though Visualize workstations are still everywhere. HP-UX was ported to run on Intel’s Itanium platform, which made sense since the Itanium family of chips are “true” 64-bit chips. The x86-64 platform, created by AMD and adopted by Intel, is actually a 32-bit chip with 16-bit memory extensions mapped to a 64-bit space; in other words, a 48-bit chip. But hey, who’s quibbling?

In any case, Itanium Visualize workstations didn’t really sell, so they are already “end-of-life” per HP. So where does the medical imaging industry go? Given the extremely high quality of Visualize workstations, can commodity PC hardware really take its place? And sure, Red Hat Enterprise Linux is nice, and I’m seeing some locations moving to it. But how does RHEL compare for critical operating environments? HP-UX has a version specifically committed to COEs, and is widely acknowledged in the industry as the most reliable Unix for at least those situations.

RHEL will have the advantage of running on ultra-fast x86-64 processors, and modern memory utilization methods should keep its top-end rendering performance at or above HP-UX. And certainly contemporary graphics cards are just through the stratosphere, so that should work too, though I can testify from experience that making extreme-high-end graphics cards work on RHEL machines calls for some very detailed tinkering at the config file level. But it is workable.

So maybe it’s okay that RHEL is where it is now, and that HP-UX is a fading star. But like everything in the extremely conservative medical universe, that just means it will be around for another couple of decades or so. Since I likely will be too, I recently bought a Visualize workstation off eBay, from a vendor kind enough to include HP-UX installation CDs. I won’t consider it time wasted.

Automating SSH and FTP

Automating SSH Login

SSH is generally happy accepting a hash key instead of username and password, provided you can generate your keys, and get your public key placed on the destination host. What’s ironic here is that doing things the “simple” way in Windows, in a GUI, is actually kind of elaborate, while doing it the “hard” way from the command line in Linux or Unix is pretty darn easy.

If you’re stuck on the Windows side, Leo Notenboom (“Ask Leo!”) has a nice guide to generating your keys using various GUI tools at

If you are working in Linux you can directly specify RSA or DSA keys as part of your keygen command. A truly fine example using DSA by Vivek Gite is at

Automating FTP Transfers

And Leo has a more advanced how-to at

Notice in all of this that Leo suggests using no passphrase, while Vivek shows a more sophisticated solution.

CAVEAT: see what actually works on your target system!

Good as their word, Google leaves China

The people at Google had a motto, though you don’t hear much of it any more: Don’t be evil. It looks like we can judge them for what they do, not what they say, because they warned China that they’d leave if the Chinese government wouldn’t enforce sanctions or investigate ongoing hacking activities within their borders, and against such targets as U.S. corporations, government agencies, universities – and search engines.
As I’ve said before: Google was hacked. By people looking for information. On Chinese dissidents.
Gee, I wonder who could have done that.

So Google closed up shop in China, shuttering its physical presence and forwarding its Google.cn site to Google.hk, where uncensored searches could still be performed. You could see this as walking away from a market of what’s rapidly approaching half a billion internet users.

Or you could see it as crazy like a fox. There’s a reason Google Can’t Be Evil. They’re all about transparency, availability and accessibility of information. They pwn all of us, and we all know it. The minute they look like they’re trying to hide something – ANYthing – they lose their most critical asset.

Our trust.

Thus Bravo, Google, for choosing trust over money. Those Chinese users aren’t going away; they’ll be remembering for a long time that it was Google that tried to make information free. And their own government that tried to hide it.

HP-UX Printer Management

HP-UX Printer Management

First, a warning: if you’ve been looking at the Linux printer information elsewhere on this site, stop (unless you’re interested in Linux). Here’s why:

HP-UX is a System V Unix. Thus it uses lp rather than lpr as its print facility (unlike Linux, for instance.) See this HP IT Resource Center thread for more on this subject.

Administrators can consult The HP-UX System Administrator’s Guide for a thorough discussion, “Administering the LP Spooler.”

Geeks will like the Freelab.net AIX/HP-UX Interoperability Guide for a deep technical discussion of print operations under HP-UX:

Users seeking simple answers should check below. If you’re a user, rather than a sysadmin, what printer management you do will likely be entirely from the command line.

Task Command Examples/Comments
Print to your default printer lp document

What happens:
the shell returns a printer name and a job number:


Print to another printer lp -dprinter_name document There must be no space between the -d (destination) and the printer name.
List your print jobs /usr/bin/lpstat Use this to list your print jobs and their request ID, for instance to cancel one.
Cancel a print job /usr/bin/cancel job_number The print job number looks like:
Cancel all print jobs for your user on a specific printer /usr/bin/cancel -a printer_name A user can only cancel their own jobs, unless they’re superuser.
Determine lp spooler status /usr/bin/lpstat -r

What happens:
the shell returns the spooler status:

spooler is stopped

Display lp spooler activity statistics lpana Only useful to sysadmins
Alter a print request lpalt See the man page for details.
Set a default printer setenv PRINTERDEST=”printer_name You should set this in your profile files.
Allow print requests to be submitted to the request directory of a printer /usr/lib/accept printer_name This “turns on” the print queue for a single printer.
Refuse to allow print requests to be submitted to the request directory of a printer /usr/lib/reject printer_name
Enable a printer to actually print /usr/bin/enable printer_name This enables literal printing on a single printer.
Disable a printer from printing /usr/bin/disable printer_name
Start the lp spooler (the scheduler) /usr/lib/lpsched This starts actual spooling, i.e. job scheduling and processing.
Stop the lp spooler (shut it down) /usr/lib/lpshut
Printer Directories
Printer Descriptions Directory /etc/lp/*
Printer Spool Directories /var/spool/lp/*