> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sunray-users- > [EMAIL PROTECTED] On Behalf Of Bob Doolittle > Sent: Saturday, September 01, 2007 4:52 PM > To: SunRay-Users mailing list > Subject: Re: [SunRay-Users] Re: Zones on Sun Rays coming soon? > > That's interesting. What Solaris seminars did you > attend? What was the level of interest in Sun > Ray, would you say?
Our local Sun office has montly(?) seminars on some Solaris/Sun topic. What's new in the next Solaris update, how to secure Solaris, or some other targeted topic. When the subject of zones comes up and their features, one or the other, or both is asked: When can I do NFS in a zone? When can I do SRSS in a zone? I have no idea if these are "revenue generating" questions, or just questions from guys who bought SRSS terminals on Ebay and want to do it in their basement. > We have to prioritize and offer the features we > judge best for our customers with the resources we > have available. Good management and > prioritization is what keeps costs from > skyrocketing and making products unaffordable. Of course, Sun needs to do what is going to be the more revenue generating for the company. But sometimes it's difficult to put a revenue number on the intangibles. For example, it seemed to take quite a long time for some of Sun's product's to support Solaris X86. SRSS was a good example of this. It supported Linux before it supported Solaris x86! I think decisions like that really hurt Solaris x86 in an intangible way. (If Sun is going to take forever to support their own X86 over Linux, why should I support X86? Etc). I think this was especially bad since Sun keeps saying "All you have to do is recompile". If that's all it is, then why did it take several years for all of Sun's products to come out with X86 versions? Obviously just a simple recompile takes time and human resources, but kind of see where I'm going with this? > In particular, there are many ways one could > imagine Sun Ray interoperating with Zones. They > all require effort to implement, and some may be > more interesting to our customers than others. I > get that you're imagining "zonable" to imply SRSS > running within a zone, rather than, for example, > logging users into zones. So you no doubt feel > that we should put effort into the former before > the latter. So far that seems to be the consensus > opinion. If you do the former, you sort of get the latter. Granted, the users are still sharing the zone with the SRSS stuff. It would be cool as well do have the SRSS code running in one zone, and user processes running in other zones, based on UID/GID, etc. > I think the request we hear loudest at the moment > is faster video performance. That has nothing > to do with Sun's other products. How does it > balance against this request? See my other comment about CBT :). SRSS is obviously completely usable without it being zone-able. I would guess higher video performance would be a higher priority for Sun, and I couldn't fault them for that. Given the load and stress that interactive users can put on a system, I would lean more towards deploying SRSS on dedicated systems rather than a zone, therefore full motion video would probably be more important to me. Small business customers who can't afford clusters of 2900s might feel differently. _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
