Monday Oct 15, 2007

Green FUD

CLAIM:  The Sun Ray has no on/off switch, thus wastes power.

They've got us there, at least with the Sun Ray not having an on/off switch.  Since administrators don't need to touch Sun Rays our customers have told us there is no need for one.  Sure there is the occasional complaint, but nothing that merits a change.  Power cycling the Sun Ray can be controlled via the keyboard.  We'd be interested in hearing scenario that would require an administrator to require that Sun Ray to be powered off.  What this really sounds like is the competition taking their own instructions on how to fix a broken thin client by installing a base OS image from a flash drive and trying to apply it to a Sun Ray.

The “green” argument doesn't hold water either since a majority if not all of the competitive devices and Sun Rays use external power supplies that continue to draw power whether the device is on or off.  Only solution is to unplug the power supply or does what Sun does in our campus offices.  We have motion detectors that cut power to the whole room if it is unoccupied.  Even the best made external power supplies consume a couple of watts when nothing is connected.  But since it is Blog Action Day, I'll throw out an eco-friendly fact about Sun Ray.  The Sun Ray 2 draws roughly 4 watts and the 2FS draws about 8 (4.6 and 8.4 to be exact).  That's something the competition can't match.

The on/off switch is a legacy holdover from most thin client vendors PC heritage.  Besides being unnecessary, not having one also means one less thing that break which increases the MTBF and decreases cost (including warranty costs).

Tuesday Oct 09, 2007

Virus/Malware FUD

CLAIM:  Embedded Linux, Windows CE, and Windows XPe are just as or more secure than Sun Ray.

If their WinXPe clients are “just as secure as or more secure than Sun Ray” why has Microsoft released over 132 updates for Embedded XP?

Why does Xpe need a virus checker?

Why does Neoware offer a virus checker and enhanced firewall for Xpe?

If WinCE shares the same "security through obscurity" as the Sun Ray does, how come there are over 80 alerts issued for Windows CE by CERT?


Meanwhile, Sun Ray has had a total of four Sun Alerts raised.  Two were found internally.  Two were found by customers during testing.  None resulted in a denial of service or a data breach.  All four have been resolved and closed with zero added cost to the customer

Thursday Oct 04, 2007

Investment FUD

CLAIM:  Our Company, like Sun with Sun Ray, also makes investment protection a top priority by providing software updates to older thin clients, and insuring that their management tools are capable of managing thin clients sold as far back as 10 years ago.

If I was a customer first thing I would ask is what are the limitations of the devices that you can manage with the free version of these management tools.  What other tools do I need?  Do I need a separate server to manage the updates?  Do these tools require additional software or licenses such as MS SQL Server?   Are all of the competitors clients capable of running the latest software.  Or do they certain have minimum memory requirements or processor requirements?  Can I run the latest RDP or ICA client with the 10 year old device?

If the competition is so worried about investment protection why do they EOL models as quick as regular PC vendors do?  Why are they not ending the 3 year upgrade cycle?  Because they're protecting an investment, theirs.

Prospective customers should look at the history of Solaris and its binary compatibility guarantee to see that Sun has a serious commitment to not only your hardware investments, but those that surround your software and service investments as well.  While I know it's not always perfect, it's a better commitment than you get from most companies especially in the technology sector.  Sun Ray follows the exact same model, it's our culture.

Wednesday Oct 03, 2007

More Display Protocol FUD

CLAIM: Only raw bitmap changes are sent, not drawing commands such as used by RDP, ICA and X Windows protocols. Like VNC, "SLIM" is a very simple protocol to implement on the client, however it typically uses far more bandwidth than protocols that use drawing primitives and is more prone to screen damage.

Windows-based terminals that the competition sell employ either the Citrix ICA protocol or the Microsoft RDP protocol to communicate with a server running Windows Terminal Server. These protocols are quite similar in nature to X but are tied to the Windows GUI API (ICA to a lesser extent than RDP). On the other hand, the low-level Sun Ray protocol has no such bias and can be used by a system with any rendering API. Another difference between them and the Sun Ray protocol is that they are highly optimized for low-bandwidth connections.  This is accomplished via a variety of techniques, including Windows object-specific compression strategies (run-length coding of bitmaps), caching of Windows objects and state at the terminal, and maintaining backing store at the terminal.  Because the resources included in the terminals directly determine the performance and bandwidth savings possible, these types of systems can have expensive terminals which constantly require upgrades to improve performance.   Consider that last sentence for a moment.  If it is not true, then why do the competition offer so many different models with varying amounts of RAM, CPU's, graphics cards, flash storage, and operating systems?

Sun Ray interprets the ALP rendering commands into a local frame buffer which drives the raster refresh to the display.  Original ALP rendering commands were set pixel, fill rectangle with solid color, expand bitmap, expand transparent bitmap, copy screen area, and color space convert/scale YUV pixels to RGB pixels.  Call me silly, but those seem like "drawing commands" to me.  Since the release of SRSS 1.0, there have been a number of other rendering commands added such as LC and DWT for Low Bandwidth and Zero Width Line Fills/Fill List of Spans for local rendering (what the competition calls primitives).  The Sun Ray protocol also has features for dropped and out of order packets, screen damage protection so these claims by competitors are not only unwarranted, they are plain wrong.

You can view an older blog entry comparing and contrasting ALP and ICA here.  The beautiful thing is when they are used together, it's the best bandwidth scenario of all! 

Tuesday Oct 02, 2007

Display Protocol FUD

CLAIM:  The contents of the virtual frame buffer get sent to the Sun Ray client using Sun’s proprietary “SLIM” protocol, which is somewhat similar to the open-source VNC protocol.

The competition is clearly reading  white papers from 1999 and picking low hanging fruit since  “SLIM” was a name chosen while trademarks and patents were being completed for the Appliance Link Protocol (ALP).  Would it be fair to compare the competitions thin client offerings or protocol support from 1999?  We choose not to do so since it's highly unethical, not to mention embarrassing for them.  Sun Ray has always had 24 bit color, CD quality audio, bi-directional audio and could play 30 Frames per second with ShowMeTV and MPEG-2 movies.  

Comparing ALP to VNC on one hand is a compliment as both are protocols which is independent of any operating system, windowing  system, and application.  A key difference between the two approaches is the manner in which the display is updated.  With the Sun Ray protocol, updates are transmitted from the server to the consoles as they occur in response to application activity. VNC, on the other hand, uses a client-demand approach. Depending on available bandwidth, the VNC viewer periodically requests the current state of the frame buffer. The server responds by transmitting all the pixels that have changed since the last request. This helps the system scale to various bandwidth levels, but has the drawback of larger demands on the server in the form of either maintaining complex state or calculating a large delta between frame buffer states.

Most people in the server based computing industry have used VNC and while most would agree it is an interesting technology that fills many needs, most will also agree that their experience with the VNC protocol is that even in low-latency, high-bandwidth environments VNC is sluggish at best and not a good solution for a thin client protocol. Thus the competitions comparison of ALP to VNC and calling them “somewhat similar” is done to invoke thoughts of sluggish performance, no device access, no multimedia features.  Further complicated by a connection process of having launching the VNC server and then telling the VNC client which server instance and port number to connect to.

Monday Oct 01, 2007

Device Management FUD

CLAIM: There is absolutely no difference between updating our thin client software with our client management tools and updating Sun Ray firmware using Sun Ray Server Software.

Linux, Windows CE, and Windows XPE updates vary between 11 MB and 209 MB.  Sun Ray firmware is roughly 500KB - 600 KB depending on whether you use the VPN enabled firmware of not..  Some competitors tout free tools, yet require an enterprise license to manage more than 5 devices.  Not all competitive devices can take advantage of the latest software updates.  Most other solutions require separate servers to run the client management stack.  These separate servers not only require OS licensing, some require database access licenses.  Those are pretty big differences.

Note too that competitor's thin clients have the “capability” of installing “packaged applications” which permit the end user to run additional software components locally on the thin client. This in itself defeats the whole purpose of our competitors “thin clients” as under this banner, they still supply devices that require management on par with most fat clients sold today.

For a fun exercise, read all the release notes of the different operating systems offered by the competition so you can get an idea of the OS matrix that you will have to support and all the different caveats noted for this version and that client.

Friday Sep 28, 2007

OS and Client Security FUD

CLAIM: What really provides virus protection for the Sun Ray is the lack of viruses written for it.  Sun Ray has an OS on par with Embedded Linux.

Perhaps the other side of the coin is that the Sun Ray was designed with security in mind and that the protocol affords for an extremely small instruction set that the competition can't match.  The only commands that a Sun Ray executes locally on behalf of a user (but not instructed by a user) are drawing primitives – no application code is ever executed locally and no install is possible – and so no virus can infect a Sun Ray.

Consider the following question:  What OS does your printer have?  The point is that an "OS" that runs any user applications or requires configuration is not required on a Sun Ray.  In fact, the Sun Ray 1 line (1/1G, 100, 150, 170) only had 640 KB of flash.  The Sun Ray 2 line (2, 2FS, 270) only have 4MB, of which the Sun Ray currently uses a maximum of about 500 KB.  With IPSec/GUI Firmware features, we bumped that requirement up to a whopping 600KB.

While you consider that, here's what the competition refers to as the Sun Ray “OS”.

There is a boot flash contains a 64 Kbyte boot sector which performs POST and DSA signature checks, a 64 Kbyte emergency firmware loader to deal with bad/nonexistent firmware, and a 3900 Kbyte firmware region which holds the firmware image that is used to implement the desktop unit portion of the Sun Ray product.  The flash also holds a 4 Kbyte unit configuration area to store preset network/unit parameters.  The configuration area is optional in Sun Ray Software 4 Update 2.  There is no user data stored in the flash device unless you are using this optional firmware, and even then it will default to prompting you for this information instead of storing it.

There is a DSA signature check before and upon loading a new firmware update. The DSA signature check verifies that the firmware and loader modules are signed by the firmware production signatures to verify that the firmware has been produced by Sun or if an OEM of Sun Ray, by that OEM for their Sun Ray technology.  This means that even an OEM of Sun Ray technology could not perform a firmware update on a Sun produced Sun Ray, or vice versa.

Thursday Sep 27, 2007

Stateless FUD

CLAIM:  We are stateless too!  All RDP or Citrix Connections are stateless!

This is all about how you choose to define statelessness.

To Sun and many of our customers who deal with highly sensitive data, being stateless means only transient, cached state (such as frame buffer content) is permitted in Sun Ray devices ; the servers maintain the true state at all times. No userland applications run on the Sun Ray.  Thus, the user is isolated from desktop failures and may move freely between terminals.  In our implementation, users can simply present a "token" (i.e. smart card or NSCM Login) at any desktop, and the screen is returned to the exact state at which it was left.

The first sentence in our definition merits a deeper look, best explored by what is stored in the Sun Ray.  This is something the competition can't back up, not even with their thinnest OS.

Sure RDP and Citrix connections are stateless, but the client used to access them is not.  Review Letters of Volatility (LoV) and see what registers get zeroed out on a power reset.  If any information about the network, servers, or users is left over the device is not stateless.  

Wednesday Sep 26, 2007

Protocol FUD

CLAIM:  The optional UDP protocol requires a DHCP server to be accessible to the Sun Rays, and also uses custom DHCP tags to locate the Sun Ray Server. This enables Sun Rays to be installed without requiring any local configuration or setup of the client itself.

Optional UDP Protocol requires DHCP?  Someone needs to do a little reading up on TCP/IP, not to mention  basic networking.  It's true that the display protocol is UDP driven, but it is not optional.  If by installing you mean opening a card board box and setting on a desk and never having to touch the device again, then we see eye to eye on that point.

Regarding "custom" DHCP tags, this is more FUD.  The Sun Ray used to required DHCP vendor tags to discover the server.  You still can do that since we care about backward compatibility for existing deployments.  MS uses vendor tags too, have customers check their  MS DHCP Server.  Other options for a Sun Ray locating the server are using DNS entries and broadcast.  We also offer multiple ways of using DHCP and DNS in case the option (49, 66) may be already in use at the customer.  Also with the newest rev of Sun Ray Firmware, you can choose to store this information in the unit so DHCP becomes optional.  This however adds more state to the device (we'll cover the "me too" stateless claims tomorrow).

The competition loves to bring up UDP, and they love to point out that the U stands for unreliable (when it really stands for user).  The benefit of using UDP is in  avoiding the overhead of checking whether every packet actually arrived.  This is like watering a plant, you don't need to watch every molecule of water hit the plant, you know another one will come along shortly to do the job.  

This makes UDP faster and more efficient, at least for applications that do not need guaranteed delivery.  Since most users are updating their screens somewhat regularly it's our opinion that UDP makes for an excellent choice when drawing the screen.

Customers may be interested in these other UDP powered  technologies such as DNS, IPTV, VoIP, tftp, video teleconferencing, and many others.  Why do these technologies choose to use UDP instead of  TCP?  Quite simply because they have real-time delivery requirements that TCP cannot reliably satisfy. Hence, the Sun Ray protocol is generally more responsive in real-time, especially in unreliable networks, where TCP may experience retransmission back-off.

This can be demonstrated nicely by disconnecting the network cable from a Sun Ray and from another device whose protocol uses TCP, and then plug the cables back in. The Sun Ray will start back up immediately; the other device will not. The TCP based protocol device will wait for the backed-off TCP retransmission timeout.

Furthermore, what the competition fails to understand is that Sun Ray stack is not purely UDP based, though they often misquote that it is.  The authentication protocol is TCP based and it handles session identification and server location.  The remote device protocol is TCP based and it handles things like printer, smart cards, USB Mass Storage, serial, parallel, and libUSB devices.  The grouping manager is UDP based which handles simple fail over and session location.

Tuesday Sep 25, 2007

Networking FUD

CLAIM: New models of Sun Rays optionally support connecting over a switched Ethernet IP connection.

False.  Since the very first Sun Ray 1 in 1999, Sun Rays have always connected over a switched Ethernet IP connection.  In fact there is no “optionally” involved, although you could use a hub if you wanted.  What is the competition trying to say here?  That they support Token Ring, Banyan VINES, DECnet?  This is FUD in it's purest form.  It's true we used only support "private interconnects" (Still TCP/IP, still ethernet, still switched) but that recommendation is no longer used.  Even when we had this recommendation, others deployed it differently.  We still support this option because some customers actually like to segment network traffic whether through cable plant or VLAN technology.

The Sun Ray display protocol has always been routable since it's based on TCP/IP.  Another embarrassing correction to the competition.  Limitations on support were due to other features in the Sun Ray product, mainly surrounding how to tell the Sun Ray what it needed to know to find a server and apply firmware.  This is just more FUD and we can cite reference of customers running in routed environments during our initial release of the software (year 2000) such as Michigan Technical University.

Monday Sep 24, 2007

FUD Fighting

There's a lot of Fear, Uncertainty, Doubt (FUD) out there regarding Sun Rays.  Most of it being driven by our thin client competition.  I've even seen a "white paper" that claims to tell the truth about Sun Rays, then adds a disclaimer at the end that they don't stand behind anything in the paper.  Nice.

Over the course of the next few weeks, I will be taking on these "truths".  Let's start with the claims of Sun Ray being "proprietary".

Claim: All Sun Ray clients must connect to a proprietary Solaris Sun Ray Server

False.  We've had Linux support for years.  While we may not support the distro you want to run (i.e. Ubuntu), at least it's there and supported on two major distros.  There is also FUD here with the word proprietary being used.  Is Solaris, an OS that can be installed on SPARC, AMD, Intel based chip sets proprietary? Is Microsoft open sourcing their OS?  No?  Perhaps instead of proprietary, the competition meant to talk about market share.  That just doesn't strike as much FUD into the minds of the customer though, does it?  Especially when you can get to windows via RDP or ICA via the Sun Ray Server easier than you can do it on the competitions devices.




Think Thin is a collection of bloggers that work with Oracle's Virtual Desktop portfolio of products.


« September 2016