On 2012/04/27 14:43, Andy Blanchard wrote:
On 27 April 2012 22:18, jdow <jdow@xxxxxxxxxxxxx <mailto:jdow@xxxxxxxxxxxxx>> wrote:
Now that you've had your rant, he is talking an embedded system. Remember
that when you contemplate the following. Suppose for a moment that this
is a theatrical lighting console application. (I know of at least one that
runs Linux underneath.) It won't be connected to the Internet, at least
not directly. If the theater's system architect has the brains God gave
a toad or if he's been reading the right lists he'll know to put the
theatrical control Ethernet on its own wires or at least its own virtual
network if glitches can be tolerated. One node would provide for the
business office monitoring of the network with a strong firewall running
on a machine running no services.
OK, that piqued my curiosity enough to make me put away the popcorn. OP's
domain was "datacast.com <http://datacast.com>", which didn't bode well for the
"disconnected" aspect and one quick look at www.datacast.com
<http://www.datacast.com> seems to confirm that. They make appliances for
streaming media content between the content makers and those who are going to
broadcast it, some of which are IP enabled, (which fits with the 2TB HDD
mentioned - it's probably for local buffering). I doubt very much that data
transfer is going to be entirely over private circuits, somehow... Hopefully,
yes, given the media business' paranoia over piracy, but in practice - I think not.
For about 8 years in the previous decade I worked in that industry. It is
rather difficult to get software updates into their offices even working
from the inside even with remarkably small stations.
From another angle the cost of downtime due to a rather typical (even with
Centos) update issue is very high. The cost of getting hacked is much lower,
at the moment. So they make the reliability decision. Unwise or not this is
a customer driven issue. "Embedded" means, to them, that it is not going to
change and possibly cost them revenue. They don't operate on big margins that
could absorb thousands of dollars a minute outages.
{^_^}
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
