Here are a few cents worth on the general topic. Historically development of a large SunRay user base has been limited by several factors: 1. Availability only on Solaris/SPARC 2. Demands of the architecture (both CPU and network) 3. (I believe) Sun's inability to really address the diverse needs of SunRay users.
Here goes on each! 1. Solaris/SPARC simply never has had a body of userland applications developed for it in the same way as the Mac, Windows or Linux platforms. Although Linux applications can be run remotely through SunRay servers to the SunRays, a big limitation has been the nonexistance of a standard, reliable and generally accepted network sound service on Linux. This means that remote Linux application machines don't always "speak" on SunRays. Citrix is good with multimedia for Win applications and works well but has not been cost justifiable for most small enterprises. Win2000 TS had very limited colour and no sound so is unusable for a large number of applications. Win2k3 TS works well with multimedia on the latest rdesktop on the SunRay Linux platform --so should run on the SPARC platform as well. My take is that this hasn't been working on earlier versions. A big problem is that we need to set up a set of interdependent servers and services that adds layers of complexity and cost to the "SunRay system" in order to provide a diverse application set. What positive spin can we put on this as a result of recent Sun SunRay developments? SunRay for Linux means a number of things: (a) SunRay users are no longer limited to the application-poor Solaris/SPARC environment. We can run SunRays on user application laden Linux machines. (b) the mess of network sound daemons and protocols in Linux is irrelevant since SRSS 3 neatly grabs local sound happenings and can deliver them to the client. Linux apps delivering sound (including sound from rdesktop/WindowsTS) work through the SunRay often with less difficulty than getting them to work under LTSP. (c) Cost of x86 hardware is historically lower than SPARC (though Sun now seems to match cost/performance of the 2 platforms quite closely) 2. Demands of the architecture have limited wide adoption. On SunRays, final display rendering added CPU load to the SunRay server -- on relatively expensive SPARC hardware. The result was oversubscribed CPUs even when applications were offloaded to remote servers. A Sunray server could become quickly compute bound when running applications, jvms, flash and the Xserver as well as doing terminal management. On multimedia applications, the SunRay in most deployments was just not competitive. Now that Sun has brought SPARC hardware more into line with commodity x86 pricing (and released SRSS3 for x86 Linux) and greatly improved the SRSS software performance in V3, a deployment can be made that is competitive with other systems for more graphics intensive applications. The networking demands of the SunRay client could also be an issue especially when Gigabit ethernet was costly. Now with gigabit backbones commonly available and the very much reduced bandwidth demands in recent SRSS software, the network resource demands have dropped dramatically. The performance of our 5 year old clients gets better over time! 3. Sun's inability to really address the diverse needs of SunRay users has limited popularity of the platform. Since the dot com collapse, I think Sun has had real difficulty getting its act together vis-a-vis the entry-level market, Linux and ubiquitous very low cost clients and servers. At least one list contributor described how slow they have been to react to demands. This was true for the Linux deployment of SRSS and appears to be still true in making SRSS available for current Linux versions. But Sun has moved on market demands; its offerings seem to be very much more competitive to a wider number of users: SPARCs are faster & cheaper; Opterons are available. The development that has been done on SRSS has shown they are still committed to the product. Sun has done a great job in dealing with (1) and (2). The improvements in SRSS are very significant. It would be great to see Sun really commit to Linux deployment across a less limited set of Linux distributions and move to drive the unit cost of SunRays down to gain market share. Recent SRSS versions have made the SunRay a broadly attractive thin client. IMHO Sun's real competition in the thin client space comes from the Linux Terminal Server Project (LTSP) which has an active development community and very quickly growing user base, runs on a wide range of hardware in different configurations to meet differing performance needs. The approach of the LTSP project is antithetical to Sun's in lots of ways and both offer different sets of advantages. And now that both can be delivered from the same servers, there's a real chance for comparison. That'll be competition! I think I'll have to try it out! Owen O'Donovan Battlefords School Division #118 North Battleford, Sask Canada -- Open WebMail Project (http://openwebmail.org) ---------- Original Message ----------- From: [EMAIL PROTECTED] To: [email protected] Sent: Thu, 31 Mar 2005 07:32:59 +1000 Subject: Re: [SunRay-Users] I wonder why Sunray doesn't take more portion in Thin Client Market? > Hi, > We only need a few MS Office licences (admin) as all students and > teaching staff have to use StarOffice. The CAL licences are not that > expensive compared with all other licences including anti-virus and > MS etc. With the ability to save as a PDF file, SO is really > usefull. Also, its clip art is much better than Office both in > variety & usability. The Drawing module is very usefull for us > also. We only use MS access for things like Encarta when the > Internet goes down (not often). Also, the Junior students do use > some MS apps for literacy, but, with site licences, the cost is > bearable. Java apps & Internet based programs really remove the need > for standalone apps on FAT Clients in education. The reality is that > a full time person to support 120 desktops would be required, > however, I am only 0.6 and teach JAVA to 100 12 year olds as well!! > Regards, Brian. > > --- > Brian Riley, > IT Coordinator, > St.Thomas More's School, > Hadfield 3046, > Melbourne, > Australia. > www.stmhad.melb.catholic.edu.au > ph: 061-3-93066225 > > -- > This email and any attachments may be confidential. If > received in error, please contact us and delete all copies. > Before opening or using attachments check them for viruses > and defects. Regardless of any loss, damage or consequence, > whether caused by the negligence of the sender or not, > resulting directly or indirectly from the use of any > attached files our liability is limited to resupplying any > affected attachments. Any representations or opinions > expressed are those of the individual sender, and not > necessarily those of this school. > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users ------- End of Original Message ------- _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
