Re: Flash, Youtube and Thin Clients

The youtube.com flash video player *used* to have a very useful feature 
in the right-corner - it sized the video down from normal to about 3/4 
size. This made it very usable in my LTSP network. They have since 
removed that feature from the player, I believe. They seem to do that 
with a lot of things.

I wish there was a better quality setting for flash (I seem to remember 
seeing one in Gnash) so you could turn down the quality for better 
bandwidth utilization. It sure would be nice for us LTSP folk to get 
some representation in situations like this - What ever happened to the 
base concept of X11, where everything was built with remote displays in 
mind?

David Van Assche wrote:
> Is it just me, or does everyone else also block everything that has
> you tube like content (bebo, <other>tube, youtube, myspace, facebook)
> through their dansguardian?
>
> My solution, which really is something that works while local apps
> gets ready for a production server, is to make some of the clients
> fat, and force flash heavy lessons on those clients... not a nice
> solution, and horribly complex firewall/dansguardian rules
> sometimes.... network friendly flash content and intermittent printer
> failure is the biggest thing currently plaguing our pilot ltsp setup.
>
> location: Marbella, Spain
> stupidly powerful server with 150 thin/fat clients
>
> Kind Regards,
> David Van Assche
>
> On Wed, Sep 3, 2008 at 4:13 PM, Jim McQuillan <[email protected]> wrote:
>   
>> Warren,
>>
>> Thanks for taking on this adventure to make flash/ltsp work better together.
>>
>>
>> Warren Togami wrote:
>>     
>>> I had a talk with someone from Adobe today about our problem with Adobe
>>> Flash, Youtube and Thin Clients.
>>>
>>> A video of 320x240 resolution at 30fps uses ~70Mbit/sec bandwidth.  This
>>> kind of bandwidth is completely unusable for thin clients.  For safety
>>> reasons many of us are forced to disable Flash plugin on our LTSP
>>> servers in order to avoid killing our networks with only a few clients
>>> swamping all available bandwidth.
>>>       
>> Makes local apps that much more appealing.  Keep the media stream
>> compressed until it reaches the thin client, then decode and display it.
>>
>> I don't think local apps is quite ready for prime time, but it's getting
>> there.
>>
>>     
>>> This is a shame, because Flash is plenty useful without Youtube and
>>> similar videos.
>>>
>>> I had an idea, what if there were a boolean option in /etc/adobe/mms.cfg
>>> that could turn off playing of .flv movies?  Then Flash could remain
>>> very useful for LTSP thin clients, and we wouldn't have to disable it
>>> entirely for safety reasons.
>>>
>>> Adobe is hesitant.  They say that this is only a policy problem:
>>>
>>> - We should simply tell users not to use any Youtube-like video.  This
>>> is simply an unreasonable expectation.  Even if all users knew to avoid
>>> it, it is simply too easy these days to accidentally load a page with
>>> embedded Flash video.
>>> - We should use QoS to throttle bandwidth between the terminal server
>>> and thin clients to protect the network from this kind of failure.  This
>>> adds complexity in network configuration, and indiscriminately punishes
>>> all applications, while being ineffective to solve the problem.
>>> - We should block all possible video sites at our proxy server.  This is
>>> problematic because there is an arbitrary number of video sites out
>>> there growing all the time.  Also the below reasons apply.
>>> - We should block all .flv URL's at the proxy server.  This sounds
>>> pretty good and would be the simplest workaround, except this fails for
>>> several reasons including:
>>> 1) Not every site has or wants proxy filtering.
>>> 2) A site may want normal desktops to be able to use .flv video while
>>> disabling it only on the LTSP server.
>>> 3) It is impossible to selectively filter .flv on a https server.
>>>
>>> I am suggesting to Adobe in response that these suggestions require us
>>> to jump through hoops, adding lots of complexity and are ultimately
>>> ineffective in solving the problem.  Meanwhile a tiny change to their
>>> plugin to implement a boolean variable for an optional config file would
>>> enable a complete and simple solution, where Flash remains plenty useful
>>> for many other non-video uses.
>>>
>>> The alternative that we are forced with if they do not agree to this
>>> simple request: We must disable the plugin on our terminal servers in
>>> order to protect the stability of our networks.
>>>
>>> To be fair, Adobe didn't know that we existed as a very sizeable
>>> deployment base of Linux desktops until this conversation.  Also they
>>>       
>> They must have gotten rid of all the old Macromedia developers, because
>> 6 years ago, they sure knew about LTSP, when they had a SHM problem with
>> the flash player that prevented it from working at all on remote X
>> displays.  We had a petition representing something like 1.3 million
>> users.  We forwarded that on to Macromedia, and the problem was fixed.
>>
>>     
>>> are very late in the Flash Player 10 development cycle and any change,
>>> no matter how seemingly simple, can create risk.  I would suggest
>>> however, that in this case the benefit is very large, while the risks
>>> are small.
>>>
>>> I am asking for the support of all Linux distributions before I approach
>>> Adobe with a stern but polite appeal.  May I count on your leadership's
>>> co-signing in asking for this option?
>>>
>>> Do you run a school or business with LTSP and have been plagued by this
>>> Flash video bandwidth problem?  Please let the list know your
>>> organization, location, and # of thin clients affected.  I would like to
>>> include this as a random incomplete sample of affected users when I
>>> submit the formal letter.
>>>       
>> I've got a site with about 55 thin clients.  I'll help in any way I can.
>>
>> Jim McQuillan
>> [email protected]
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _____________________________________________________________________
>> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>>      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
>> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>>
>>     
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _____________________________________________________________________
> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>   

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net