Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.filibeto.org/mailman/listinfo/sunray-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SunRay-Users digest..."
Today's Topics:
1. Re: Top 3 of new Sun Ray features (Craig Bender)
2. Re: Top 3 of new Sun Ray features (Ivar Janmaat)
3. Re: Top 3 of new Sun Ray features (Wim Coekaerts)
4. Server Side Graphics Processing (was: Top 3 of new Sun Ray
features) (David Bullock)
5. Regarding Flash 10 Content (Craig Bender)
----------------------------------------------------------------------
Message: 1
Date: Wed, 01 Sep 2010 12:57:48 -0700
From: Craig Bender<[email protected]>
To: SunRay-Users mailing list<[email protected]>
Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Folks,
I apologize if anyone took this to mean we are not pursuing local decode
solutions, or that I was trying to push Ivar away from wanting local
decode. That is neither the case, or my intent.
I was simply trying was to highlight that while RCA may be more
"expensive" in terms of scalability, it has it's place when usability is
a concern.
At the very least, RCA buys us time to further develop and enhance our
existing technologies such as direct decode without impacting end user
experience.
On 9/1/10 10:11 AM, Craig Bender wrote:
On paper direct decode looks like a better option, and in some cases it
is indeed the better option. Like:
A purpose built hardware device, or features in an existing devices
chipset, dedicated to video processing. Typically these only support a
few formats due to putting codec either in the hardware on in the RTOS.
Rarely do the codecs in the device support every possible encoding
option, so even video that is "supported" at the higher level of the
spec, might not play on device. Codec development takes time, and in
many cases the vendors of the purpose built device need to license
technology from 3rd parties even though there is a free (to use) Windows
codec. The biggest problem with the purpose built device though, is it
usually does only one thing. And if it does more than one well it
usually costs as much as a PC, but doesn't exactly replace your PC.
The other would A device that allows the somewhat easy installation of
readily available codecs. Usually this means windows, but definitely
means a fat OS. I say somewhat easy installation because things rarely
just work. You might get prompted to install a codec, you might have to
manually research what codec is needed. There might not be a codec for
your OS available, or it might not be free.
Then you take thin clients. They have the problems of the purpose built
device, with the added the complexity that they really weren't built for
video. Sure the chipset may have some codec support (usually parts of a
codec that are "free") but not only do you have to write firmware to
access the codec and software to stream it down to them, but you have a
problem with updates to the video format spec itself. They are
constantly changing and you wind up having to either replace the
hardware or someone has to start writing software drivers, and
eventually you have locked down PC.
Just like the Sun Ray "future proofs" the device from desktop (i.e.
display almost any desktop on the same device), RCA future proofs the
multimedia from the codec required on the display device.
It may require more processing at the hypervisor layer, or some cases
the Sun Ray Server layer, and it may not be as efficient bandwidth wise
as direct decode, but it makes things usable. And at the end of day,
it's not usable, it's not worth buying.
The problem with purpose built hardware is that
On 9/1/10 8:33 AM, Ivar Janmaat wrote:
Hello,
The advantage of MMR is that it uses less resources on the server since
it is offloading the decoding to the Sun Ray.
This will scale better then vrdp. Although not yet tested I suspect MMR
will use less bandwidth which would give better performance over WAN.
#3 means indeed a separation between the system disk c: and the
documents and settings disk d:
I used this a lot in implementations with Virtual Bridges since they
have had this feature already 10 years ago.
I noticed that you can not select this feature if you use LDAP or Novell
directory servers. It can only be used in combination with AD.
Kind regards,
Ivar
Wim Coekaerts schreef:
have you tried vdi3.2 with vb as the hypervisor and vrdp ?
it plays flash just fine for windows xp,7, linux etc
not sure what #3 means. I guess you mean the new feature in 3.2 where
you can replace only the system disk and keep the user disk. I didn't
realize that didn't work with ldap
Number 1:
Flash 10 content support in MMR on Windows XP.
Number 2:
MMR support for Windows 7
Number 3:
Personal data disk for other directories than AD.
I hope this helps to give some direction for future development.
Kind regards,
Ivar Janmaat
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 2
Date: Thu, 02 Sep 2010 00:13:17 +0200
From: Ivar Janmaat<[email protected]>
To: SunRay-Users mailing list<[email protected]>
Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello Craig,
I appreciate your input!
A few years ago my opinion on the implementation of MMR was rather
negative because in my opinion the ultimate ultra thin client should
only handle generic codecs not specific Flash and MS codecs of a
specific version. The RCA method is much more in line with my thoughts
on how the ultimate ultra thin client should operate. You definitely
don't want to end up with an obese client stuffed with all sorts of codecs.
So I like the Virtualbox - RCA - Sun Ray combination. Since Virtualbox
supports 3D acceleration, this combination can be very strong.
(I would like to see some sizing figures on the 3D acceleration though)
At this time however the VM market is still dominated by VMWare and KVM
type VDI solutions which come with all sorts of application management
tools.
If you want to position the Sun Ray as a client for those VDI
infrastructures, you need something else than vrdp (RCA).
This is where MMR kicks in. Other options are also possible like pcoip
or spice. I have discussed those before.
The problem with MMR is that it is badly crippled since there is no
Flash 10 content support at this time.
It would be a good idea to put Flash 10 content support in MMR before
Flash 11 arrives.
Then the Sun Ray would also be a good client for current VDI locations
where they don't use Virtualbox.
So eventually it is not only a technical choice. It is also a choice
between selling Sun Rays solely with Virtualbox or selling it also with
other VM solutions.
I think the broker function of the Sun Ray is unique in the market. So I
would favor superb connection protocols to all VM/VDI solutions. This
would enhance the broker function even further and lift the product
above other offerings in the market. That is why I asked to fix the
crippled MMR functionality by supporting Flash 10.
If Oracle however does not fix the MMR then I need to conclude that
Oracle has already decided to sell Sun Rays only with Virtualbox.
That would limit the broker function of the Sun Ray server which
basically means that the solution will become the same as all other
solutions in the market.
With head to head competition it will than be much harder to build large
volume Sun Ray sales.
Kind regards,
Ivar Janmaat
Craig Bender schreef:
Folks,
I apologize if anyone took this to mean we are not pursuing local
decode solutions, or that I was trying to push Ivar away from wanting
local decode. That is neither the case, or my intent.
I was simply trying was to highlight that while RCA may be more
"expensive" in terms of scalability, it has it's place when usability
is a concern.
At the very least, RCA buys us time to further develop and enhance our
existing technologies such as direct decode without impacting end user
experience.
On 9/1/10 10:11 AM, Craig Bender wrote:
On paper direct decode looks like a better option, and in some cases it
is indeed the better option. Like:
A purpose built hardware device, or features in an existing devices
chipset, dedicated to video processing. Typically these only support a
few formats due to putting codec either in the hardware on in the RTOS.
Rarely do the codecs in the device support every possible encoding
option, so even video that is "supported" at the higher level of the
spec, might not play on device. Codec development takes time, and in
many cases the vendors of the purpose built device need to license
technology from 3rd parties even though there is a free (to use) Windows
codec. The biggest problem with the purpose built device though, is it
usually does only one thing. And if it does more than one well it
usually costs as much as a PC, but doesn't exactly replace your PC.
The other would A device that allows the somewhat easy installation of
readily available codecs. Usually this means windows, but definitely
means a fat OS. I say somewhat easy installation because things rarely
just work. You might get prompted to install a codec, you might have to
manually research what codec is needed. There might not be a codec for
your OS available, or it might not be free.
Then you take thin clients. They have the problems of the purpose built
device, with the added the complexity that they really weren't built for
video. Sure the chipset may have some codec support (usually parts of a
codec that are "free") but not only do you have to write firmware to
access the codec and software to stream it down to them, but you have a
problem with updates to the video format spec itself. They are
constantly changing and you wind up having to either replace the
hardware or someone has to start writing software drivers, and
eventually you have locked down PC.
Just like the Sun Ray "future proofs" the device from desktop (i.e.
display almost any desktop on the same device), RCA future proofs the
multimedia from the codec required on the display device.
It may require more processing at the hypervisor layer, or some cases
the Sun Ray Server layer, and it may not be as efficient bandwidth wise
as direct decode, but it makes things usable. And at the end of day,
it's not usable, it's not worth buying.
The problem with purpose built hardware is that
------------------------------
Message: 3
Date: Wed, 01 Sep 2010 16:07:40 -0700
From: Wim Coekaerts<[email protected]>
To: [email protected]
Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
we are improving that as well... (rdp rdp7 rca etc)
I would agree with your vmware comment but seriously disagree with the
kvm/spice stuff. that's still no where and I can tell you that there is
no interest there.
On 09/01/2010 03:13 PM, Ivar Janmaat wrote:
Hello Craig,
I appreciate your input!
A few years ago my opinion on the implementation of MMR was rather
negative because in my opinion the ultimate ultra thin client should
only handle generic codecs not specific Flash and MS codecs of a
specific version. The RCA method is much more in line with my thoughts
on how the ultimate ultra thin client should operate. You definitely
don't want to end up with an obese client stuffed with all sorts of
codecs.
So I like the Virtualbox - RCA - Sun Ray combination. Since
Virtualbox supports 3D acceleration, this combination can be very strong.
(I would like to see some sizing figures on the 3D acceleration though)
At this time however the VM market is still dominated by VMWare and
KVM type VDI solutions which come with all sorts of application
management tools.
If you want to position the Sun Ray as a client for those VDI
infrastructures, you need something else than vrdp (RCA).
This is where MMR kicks in. Other options are also possible like pcoip
or spice. I have discussed those before.
The problem with MMR is that it is badly crippled since there is no
Flash 10 content support at this time.
It would be a good idea to put Flash 10 content support in MMR before
Flash 11 arrives.
Then the Sun Ray would also be a good client for current VDI locations
where they don't use Virtualbox.
So eventually it is not only a technical choice. It is also a choice
between selling Sun Rays solely with Virtualbox or selling it also
with other VM solutions.
I think the broker function of the Sun Ray is unique in the market. So
I would favor superb connection protocols to all VM/VDI solutions.
This would enhance the broker function even further and lift the
product above other offerings in the market. That is why I asked to
fix the crippled MMR functionality by supporting Flash 10.
If Oracle however does not fix the MMR then I need to conclude that
Oracle has already decided to sell Sun Rays only with Virtualbox.
That would limit the broker function of the Sun Ray server which
basically means that the solution will become the same as all other
solutions in the market.
With head to head competition it will than be much harder to build
large volume Sun Ray sales.
Kind regards,
Ivar Janmaat
Craig Bender schreef:
Folks,
I apologize if anyone took this to mean we are not pursuing local
decode solutions, or that I was trying to push Ivar away from wanting
local decode. That is neither the case, or my intent.
I was simply trying was to highlight that while RCA may be more
"expensive" in terms of scalability, it has it's place when usability
is a concern.
At the very least, RCA buys us time to further develop and enhance
our existing technologies such as direct decode without impacting end
user experience.
On 9/1/10 10:11 AM, Craig Bender wrote:
On paper direct decode looks like a better option, and in some cases it
is indeed the better option. Like:
A purpose built hardware device, or features in an existing devices
chipset, dedicated to video processing. Typically these only support a
few formats due to putting codec either in the hardware on in the RTOS.
Rarely do the codecs in the device support every possible encoding
option, so even video that is "supported" at the higher level of the
spec, might not play on device. Codec development takes time, and in
many cases the vendors of the purpose built device need to license
technology from 3rd parties even though there is a free (to use)
Windows
codec. The biggest problem with the purpose built device though, is it
usually does only one thing. And if it does more than one well it
usually costs as much as a PC, but doesn't exactly replace your PC.
The other would A device that allows the somewhat easy installation of
readily available codecs. Usually this means windows, but definitely
means a fat OS. I say somewhat easy installation because things rarely
just work. You might get prompted to install a codec, you might have to
manually research what codec is needed. There might not be a codec for
your OS available, or it might not be free.
Then you take thin clients. They have the problems of the purpose built
device, with the added the complexity that they really weren't built
for
video. Sure the chipset may have some codec support (usually parts of a
codec that are "free") but not only do you have to write firmware to
access the codec and software to stream it down to them, but you have a
problem with updates to the video format spec itself. They are
constantly changing and you wind up having to either replace the
hardware or someone has to start writing software drivers, and
eventually you have locked down PC.
Just like the Sun Ray "future proofs" the device from desktop (i.e.
display almost any desktop on the same device), RCA future proofs the
multimedia from the codec required on the display device.
It may require more processing at the hypervisor layer, or some cases
the Sun Ray Server layer, and it may not be as efficient bandwidth wise
as direct decode, but it makes things usable. And at the end of day,
it's not usable, it's not worth buying.
The problem with purpose built hardware is that
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 4
Date: Thu, 2 Sep 2010 09:53:27 +1000
From: David Bullock<[email protected]>
To: SunRay-Users mailing list<[email protected]>
Subject: [SunRay-Users] Server Side Graphics Processing (was: Top 3 of
new Sun Ray features)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Craig Bender wrote that decoding video under some scenarios may require:
processing at the hypervisor layer, or some cases the Sun Ray Server layer,
Just to parade my general ignorance on such things, when the hypervisor/SRS
is compositing screen updates (or decoding video) for its myriad clients,
is there any benefit from throwing extra graphics cards/GPU's at the
server? Or is this not a bottleneck in practice?
thanks,
David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.filibeto.org/pipermail/sunray-users/attachments/20100902/e69b4
b37/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 01 Sep 2010 17:06:30 -0700
From: Craig Bender<[email protected]>
To: SunRay-Users mailing list<[email protected]>
Subject: [SunRay-Users] Regarding Flash 10 Content
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 9/1/10 3:13 PM, Ivar Janmaat wrote:
> The problem with MMR is that it is badly crippled since there is no
> Flash 10 content support at this time.
> It would be a good idea to put Flash 10 content support in MMR before
> Flash 11 arrives.
I'm not sure I've covered this before or not, but previous discussions
concerning our lack of support for Flash v10 content, or perhaps better
stated, the versions of Flash content (v8, v9) that we state support
for, may be painting our ability to handle Flash v10 content with a bit
too broad of a brush. Perhaps we need state we support Flash v10
content with a footnote based on the following.
In short there are two "New modes" that Flash can use to push content to
the screen. These are in *addition* to the three that have been
available in the past, and are still the most widely used methods.
The first is called "Direct" with uses DirectDraw and Direct3D on
Windows platforms, and OpenGL on Linux and OSX.
The second is called "gpu" and does full fledged compositing using, you
guessed it, the gpu on the client.
While that does indeed seem like scary stuff, I believe our fear of this
feature would seem to be more theoretical than based on reality.
Most Flash content developers don't seem to be using it, unless they are
developing a solution based around specific hardware, and not for what I
would say "normal consumption". Suppose you had a flash front end to
your bank. While they may be comfortable to tell you to install Flash,
I think the Last thing they would want would be to tell people to update
to the latest Direct3D driver or OpenGL.
I'm sure there is some direct mode stuff out there, but I still can't
find an example of any GPU accelerated Flash content "in the wild".
I think most of the issues people are seeing with our Flash solution are
because of the size limitation, which is something we are addressing.
Granted 1024x768 is a fairly small area, and we've all seen more than
our fair share of out of control Flash based sites (http://www.sobe.com/
for instance.
More info here on the two new modes from an engineer from Adobe, a bit
dated, but explains the features.
http://www.kaourantin.net/2008/05/what-does-gpu-acceleration-mean.html
Finally, our Flash solution is pretty the same at a higher level as RCA.
Both use motion jpeg. We don't have a "Flash" codec in the the Sun Ray,
so it's not "MMR", or at least it's not local decode of Flash content.
I believe by the time you actually see Direct or GPU mode as a standard
or normal way of writing Flash based content (if HTML5 doesn't kill
Flash), we should have a solution.
------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
End of SunRay-Users Digest, Vol 80, Issue 3
*******************************************
