[K12OSN] Flash, Youtube and Thin Clients
moon at smbis.com
Wed Sep 3 04:34:48 UTC 2008
Warren, here is my input.
Organization: Holy Ground Baptist Academy
Location: Carrollton, GA 30117
# of thin clients affected: LAB 1 - 8 PCs (Grades K-3)
# of thin clients affected: LAB 2 - 24 PCs (Grades 4-8)
We had been running Edubuntu up until this August, when I switched
everything over to K12LTSP EL5. The reason for the switch was due to
Edubuntu's poor performance and instability.
From: Warren Togami [mailto:wtogami at redhat.com]
Sent: Tuesday, September 02, 2008 11:57 PM
To: ltsp-developer at lists.sourceforge.net; Support list for opensource
software in schools.
Subject: [K12OSN] Flash, Youtube and Thin Clients
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.
This is a shame, because Flash is plenty useful without Youtube and
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
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
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.
wtogami at redhat.com
K12OSN mailing list
K12OSN at redhat.com
For more info see <http://www.k12os.org>
More information about the K12OSN