|
This topic comprises 2 pages: 1 2
|
Author
|
Topic: Auto-update
|
|
|
|
Steve Guttag
We forgot the crackers Gromit!!!
![](http://www.film-tech.com/ubbmembers/268e.gif)
Posts: 12814
From: Annapolis, MD
Registered: Dec 1999
|
posted 10-06-2018 04:54 PM
A mandatory auto-update would be a disqualifier for use as an automation system in cinema. It is that cut and dried.
As you know, as a developer, sooner or later, you are going to send a bug out. it happens, no matter how well or long you beta test in your lab or select locations. People will always remember the time you took them down.
In fact, for me, it would need to be an "Opt-in" situation.
With our support program, we provide up to two updates per year. This is not to say that we always update everything twice a year but twice a year we evaluate what the client has, what is available and update them if there is an advantage.
When new updates come out, we, personally put them in a holding pattern for, at least a month. Too many times, a patch or update comes out and within 2-weeks gets recalled (just happened on Hollywood Software for patch 10...there is now a patch 11 to fix what patch 10 did). Again, I'm not pointing fingers...it happens. It is impossible to test for every permutation of the way a product may be used.
After the grace period, we tend to have our own "beta" sites where they know they have a new release, if not actual beta software. These sites represent the way WE have configured systems so they are a good test for US...if they pass muster there for a couple of weeks, THEN they may end up being pushed (release versions only) to other sites on the regular update program.
Critical updates that fix ongoing issues can be pushed off-schedule to relieve a site of problems.
The key here is that WE decide what and when gets pushed because ultimately, WE have to answer for a theatre being in distress.
So, if you were to put such an auto-update in that was not defeatable, I'd advise anyone against ever installing the product again as I could just about guarantee that you'd, sooner or later would negatively affect some site.
| IP: Logged
|
|
|
Carsten Kurz
Film God
Posts: 4340
From: Cologne, NRW, Germany
Registered: Aug 2009
|
posted 10-07-2018 04:46 AM
Autoupdate should be enabled by default, to cater for larger numbers of IoT devices to be protected from being abused. It should be possible to deactivate this for installers, because, if there is someone actively maintaining them, he is able to install updates intentionally as well.
With a device like the JNIOR, where you seem to be able to control the software very tightly, it is probably also a first step to analyse potential security issues and entry points beforehand and e.g. disable them, so that the user/installer need to activate them intentionally. Most abused IoT consumer devices are abused for DDoS because remote access, cloud services, etc are enabled out of the box with weak or public logins, not because of specific code weakness.
- Carsten
| IP: Logged
|
|
|
Bruce Cloutier
Expert Film Handler
![](http://www.film-tech.com/ubbmembers/9615a.jpg)
Posts: 161
From: Gibsonia, PA, USA
Registered: Aug 2016
|
posted 10-07-2018 09:08 AM
Great feedback. I am on the same page with most of you when it comes to the rest of the world. I went through a phase when I disabled updates everywhere as well. The 24/7 network connection, unsolicited updates and Easter eggs/games aspect of the Tesla knocks it right out of my interests. That's not to mention the expense of the vehicle but I don't appreciate turning something on the next day and being surprised with it functioning differently (good or bad). Or, perhaps, living always in fear that it will not do what I expect it to do the next time I use it. It won't be long before your Tesla forces you to watch an ad.
JNIOR is a bit different but let me just put my thoughts on the table and not ask that you accept them. JNIOR is my personal responsibility. I have written 100% of the operating system code it runs (JANOS). Yes, every byte. INTEG is purposely unlike the rest of the world that throws together third party and open source components in an effort to get product out quickly. JNIOR is not a device designed by committee. If there is a bug (and we can recreate it) we can fix it the same day. There are issues that take a little longer and that usually when the symptoms are random. We call those "gremlins". We had a good 'kill' just this past week (the fix now in JANOS v1.7.1-b1 Beta v1). JANOS updates are generally 98% corrective and 2% adding some new capability. We intend always to be 100% legacy compatible.
But you are right, we are human and we can make mistakes. Take some comfort that the humans at INTEG can also quickly fix their mistakes. There is no one else I can point a finger to and blame. And, oh yeah, we don't serve any wine before its time.
JANOS is at v1.7 and you would be surprised with how many support calls we get where they are running some old version where we know there are tons of shortcomings. We don't get many support calls.
Any auto-update capability would be configurable. Presently JNIOR does not 'phone home' for any reason. So its a big step.
Security is a big issue obviously for the rest of the IoT space. The JNIOR is not a Linux or Windows system and therefore does not offer the usual set of vulnerabilities. I would imagine that if someone set their mind to it they could certainly hack it or otherwise disrupt its use. It is good to keep it behind a firewall/router. And there is a big difference between JNIOR being able to get to the Internet and the Internet being able to get to the JNIOR. The former would be required for auto-update. We do have units on the open network and keep a close eye on those.
There is another approach where the Support Tool automatically gets and optionally performs the updates. But, there are a lot of old Support Tool versions out there too. I am talking only about operating system updates and not application updates which are Support Tool Update Projects. Those will always remain manual as they are now. Those are much more involved.
And to Mark's point. The JNIOR is a controller and while a reboot is necessary for an update we would never reboot for the update in any automatic sense. I would plan to have the update queue and be performed when YOU happen to reboot the next time.
| IP: Logged
|
|
|
|
|
|
|
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 10-08-2018 06:43 PM
I think that we're all on the same page that for any professional production environment, automatic updates should be off the table. No matter if the underlying system is a complex and often overly bloated OS like Windows or a Linux distribution or a more to-the-point embedded approach. Every update comes with a risk, even fixing a bug can break stuff, because my solution happened to work around the bug and the combination of my workaround and your fix might break stuff...
That being said, automatic updates being an option sounds totally fine to me, as long as I can opt-out of it and please, for anything not being targeted as a home solution, don't make it the default.
Furthermore, I hate convoluted update procedures. Many of those embedded gizmos make you jump through a 1000 hoops in order to get them updated, just to put up a few examples:
- Running a local TFTP server, because why support something "modern" like FTP or even HTTP? - Updating involves a 10-page upgrade path, in where you end up updating bootloader 1.43 to 1.45 before you can apply OS image 4.32-Mental-Green, from which you then can upgrade to 5.2-Shady-Pink - Loading a web page loading a Java applet which was signed by a root certificate expired 5 years ago - Finding the correct update requires registering to your convoluted and website (after being redirected 5 times, because the company that built your appliance was acquired by that other company which was then acquired by yet another big company that then changed its name after some other big-shot merger), often even requiring expensive subscription services, while burying the actual firmware update somewhere, 10 layers deep within a 5 mile list of useless "software listings". HP(E), Dell(EMC?), Cisco... I'm looking at you.
What I actually would like is, something like a "embedded gizmo update console"...
You know, some server or service where all the embedded "little" critters like switches, routers, access points, fridges, toasters, automation controllers... you name it... would register themselves and would allow ME to manage the updates.
Imagine all those little devices talking some common update protocol, where you can manage and enroll updates centrally, all from that same console, without the need of manually logging into each device or the need to install bloated "management consoles" from all the different vendors that come up with their own, mostly convoluted solutions. Imagine the same solution would even allow me to backup device configurations...
Something like that would obviously require some cooperation on a common API... but yeah... I'm still allowed to dream, am I?
| IP: Logged
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 2 pages: 1 2
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|