The word "pusillanimous" is normally used to label actions judged to reflect a lack of moral courage on the part of the person taking the action. Thus people who can be rather easily pressured to undertake actions contrary to their own beliefs are often said to be pusillanimous, cowardly, or weak spirited while those who advise "getting along by going along" are said to offer pusillanimous counsels.
It may not be a word you want to drop into casual conversations about middle management --but if you do be sure to have someone send a video of the reaction you get to the people at America's Funniest Videos.
On the other hand it's not just the perfect word to describe a recently released Sun document titled the "Desktop Architecture Selection Guide", it's the only applicable adjective the Editor will let me use here.
What's most disheartening about this "blueprint" is that it looks as if someone took an older source document that probably did a pretty good job of stating the case for the Sun Ray sometime in late 2000 or early 2001, and mealy-mouthed it with some minor updating for corporate release in November of 2003.
Thus references to Staroffice are to version 6 and 6.1 (June 2002) with embedded links to the version 6.0 FAQ while user authentication is linked to the federated services facilities from the mid nineties. In fact, by word count the document's emphasis isn't on the Sun Ray at all; it's on running Windows applications like "Advanced" directory on traditional Wintel clients like Citrix or Tarantula licenses.
It was reasonable, in 2000, to express some ambivalence about leaving the Microsoft client-server architecture behind mainly because critical office applications weren't yet up to the job. Today that's not true, Sun's Java enterprise desktop meets most requirements quite nicely. As a result an updated version of something which provided a reasonable balance between Wintel and Unix applications views in 2000 should now lean far more heavily in favor of the Sun Ray. This doesn't; instead the updater appears to have focused on the Windows side while assuming stability on the Sun Ray side. As a result a document which probably started with a reasonable balance, is now tilted heavily the wrong way.
An architecture document intended to help people configure and deploy the Sun Ray should assume that the reader is committed to the architecture and needs help getting it in place. Thus just summarising the cost and productivity argument for it instead of building an extended case makes perfect sense - and the Sun document's authors do provide a few paragraphs summarising the case against using Wintel, but they don't pro-actively make the case for the Sun Ray.
In reality, the case for the Sun Ray is utterly compelling and needs to be told with the kind of blunt good humour characteristic of Sun's highly unofficial bigbluesmoke site. Perhaps it's time for "coronaljet.com"?
For a small business with under 100 employees the case for the Sun Ray comes down to this: all the software needed for office automation, web services, secure document management, remote access, and IT management is free. The hardware itself is marginally cheaper to buy than the Wintel equivalent but lasts far longer and operating costs are a small fraction of their Wintel equivalents.
For example, a minimalist install with 100 Sun Ray 1g displays ($369) using Dell 19" LCDs ($679) could be split evenly between two Sun 440 servers (16GB, 4 x 1.3GHz, 4x36GB internal, 876GB external array, $47K) for a total of just under $2,000 per user inclusive of network gear and a couple of printers. That would provide redundancy along with room for accounting or other applications while requiring only one part time sysadmin and probably run for something like five years with only software updates.
For a busy office with a complex on-line application like a time based billing system and integrated VoiP communications, those 440s would be marginal. Replacing them with six way V880s improves performance, allows more room for growth, and reduces the operational impact of having one server shutdown but raises capital cost to just over $3K per user - right about what a Wintel environment would come to before business application licensing and support.
For larger businesses the case is typically even better, but the importance of a small capital cost savings and even the substantial savings in support, pale in comparison to gains in flexibility and user productivity -because getting rid of the Microsoft client-server architecture also means getting rid of all the organisational structures, like the help desk and the consequent separation of application expertise from operational support, put in place to support it.
Of course an architecture guide should fundamentally be about what it takes to deploy and support the Sun Ray desktop. When I first downloaded the document this, of course, is what I skipped to first - only to find stuff like:
There is no simple guideline for the ratio between Sun Ray ultra-thin client devices and server resources required to support them. Guidelines provided by the Sun Ray ultra-thin client engineering group suggest that each Ultra SPARCŪ III CPU can support 25 concurrent Sun Ray ultra-thin clients. Such a guideline, however, ignores other software that is running on the server and user interaction with the server. In a real world situation, the typical user might be running a Tarantella or Citrix native client to present Windows applications and might also be accessing an Internet browser and an office productivity tool (for example, the StarOffice Office Suite), running on the same or a different server. Experience in the field suggests that some of these tools might require frequent screen refreshes caused by user interaction or, in the case of the Internet browser, caused by Shockwave animations or streaming video.
Followed by truly brilliant -and Solaris specific- advice like:
Always use a server with at least two CPUs whenever possible. This avoids the situation in which a single thread spins on a CPU and locks out other Sun Ray ultra-thin clients. A thread is a section of executable code that is recognised by the operating system as a executable entity in its own right.
Not to be pusillanimimous, or even pugilistic, about it: this sucks and Sun should withdraw this document instantly.