* What makes nodejs running on an entertainment system dangerous?
* Outside of bias, how strong of a case is there to use another language?
* why shouldn't we use high level languages, even for avionics? Obviously not JS because numbers aren't transitive and it just isn't the usecase, but we don't need to optimize for 1kb of memory anymore. C family languages are the backbone of many things and that makes sense but do we need to keep using java and C-like languages or could we use python or something of similar nature where memory isn't manually allocated.
It's not that there's anything wrong with using a high-level language for safety-critical systems with real-time requirements and limited hardware. It's just that every high-level language that's remotely appropriate for this set of requirements wasn't production ready (or even conceived of) 10-20 years ago.
Hopefully the next generation (or the one after that) of control software for aircraft will be written in beautiful code :-)
Nothing against python, but it's just not suited to writing avionics code that human lives depend on.
Now, in some ideal future, could we be using better languages? Absolutely. Stuff like ATS looks like the future of that kind of code, IMO. Likewise, Rust's memory management types make a ton of sense and could be useful for the situations where static allocation can't do the job.
Not saying it couldn't in the future, but it pays to look backwards for safety critical systems.
I find that there is much less distraction when you're working on both the front end and backend, that you can get things done much more seamlessly. In this case (for entertainment), I feel it's a pretty decent match.
For other systems, I'm not sure I'd suggest C variants at this point, if Go or Rust are options, I'd probably favor one of them. It really depends on the use case.
Oh well, that isn't a problem for anyone other than the airline. It's possible that in a matter of a few years (instead of decades), the entire system will have to be reimplemented at the airline's cost. You don't use the latest trendy language for systems which are expected to remain in operation for 20-30 years.
"undefined is not a function".
Also, for something as important as an aircraft, I'd prefer to have a developer who knows what a seg fault is writing the code for any aviation equipment over someone who thinks "'undefined' is not a function" is equivalent to a seg fault.
"the crash was generally believed to have been caused by faulty wiring in the cockpit after the entertainment system in the plane started to overheat"
It's not too far fetched to think you could end up with an infinite loop (or other random issue) in some inflight entertainment system code, causing it to overhead and potentially ignite. I'm sure there are plenty of safeguards, but they too could fail...and this is why we still have circuit breakers and a master switch in planes that a human can control. Sadly humans too can (and often do...) fail to make the right decision.
Any system other than flight surfaces, avionics and the source of propulsion to an aircraft add some degree of risk that we could otherwise fly without.
Edits: Spelling and general sillyness.
I know it's a joke, but still: the in-flight entertainment system doesn't log to the flight data recorder.
Why couldn't they use Scala instead?
* in-flight entertainment system devs allowed to run
open source
* system is "online" via aircrafts satellite
internet connection
* devs pushed fixes mid-flight
Yes, the submission title here is an example of how editorializing by picking a single detail usually ends up determining the entire discussion. We didn't change it, but probably should have.
They don't say they updated the flying server midflight, though:
"An issue was spotted mid-flight, discussed over Slack with Yle (located in Helsinki) and fixed immediately. The fix was visible whilst airborne, 10 minutes later when the latest news were updated to the aircraft."
It could well have been an issue in the infrastructure on the ground which led to garbled news. Then they pushed a fix on the ground and 10m later, the flying system got rid of the glitch. Purely to make it more dramatic, I would have been vague about that too if the fix was to the ground-based infrastructure.
Scary, even if the entertainment system is not connected to the flight equipment.
Also - no matter if it is relevant or not in the case - being able to deploy and update fixes to a system in production without anyone noticing is a testament to good system design - and even a requirement in many cases.
http://www.viatech.com/en/boards/
I run a couple of servers using VIA processors, they consume very little electricity, I run storage, web and mail servers on them. When Intel came out with the Atom, it used a little bit more electricity but was significantly more performant than the VIA. VIA has had new processors since but I don't know how they compare to the Intel low-power line.
Neither of those have SloppyDevTypeCheckComfortBlankie either, do they?
Love node.js and happy to see it succeed. I'm not sure if I'm a big fan of seeing it used in places where it's not, because it gives the wrong impression.
I wouldn't use node.js everywhere. I'd say python can wear more hats, but if it came down to something you can't update regularly and would cause big ramification if it'd fail. You're just making a gamble.
If you have a JS bug which wasn't caught, which could have been caught via static analysis, you're going to either go into flight with broken entertainment or wait for a mechanic to update the system.
So to reiterate. Happy for node.js, I don't think I agree with where you applied it. I hope that customers, the airline companies and node.js doesn't suffer unduly because the wrong tool was picked for the job.
for those who don't know, typescript gives you static typechecking and builds to JS. http://www.typescriptlang.org/
That said, node.js can be embraced by being used in places where it's strongest, like packaging web assets, front end builds, package managing js libraries, websocket stuff.
While the company selling the stuff doesn't go into much detail on how node.js is used - when bugs happen - and they will, node enthusiasts are going to get a bad rep for thinking they can use JS everywhere. Not a good idea
I bet you there are not two satellite aerials on the plane and you can bet that the important navigation systems are in some way connected to the network. Hopefully this just the aerial connected to two routers but it's probably a single router. I think I want to fly on this and start running nmap ;-) I suppose that would be considered hacking though.
Also, please don't give them any ideas. It's enough that every other JS webdev company uses rocket-related imagery on their site, we don't want them to design actual rockets.
;).
Pre-recorded safety announcements get replaced by S-Club-7 on a perpetual loop? Siren noise ever time the seatbelt sign turns on? Or how about altering the hosts file so that the official news source points to hustler,com? There is something to be said for some systems not being so heavily networked.
Take the mood lighting. Once upon a time such LEDs would be tied to a controller with three knobs, three rehostats, to set the RGB values. Done. No networking, just knobs. Hacking would require digging holes into the wall. Anyone willing to do that would just turn the knobs. But now it's connected to a tablet app. The software on that networked tablet is always, always, going to be more of a risk than the software behind those not-networked RGB knobs. It's a physicality problem.
Stopped reading right there. Well, actually, I read the next header "Callback spaghetti is about the last pattern with which you’d ever want to write anything" and realized that the author has absolutely no idea what they are talking about.
I'm surprised nobody mentioned the Atwood's Law yet.
Most airlines are stuck with static, slow, and outdated in-flight systems. This will help them compete as consumers' devices have become embarrassingly better than the typical in-flight UX. Not to mention consumer devices are much heavier on bandwidth and power usage.
In regards to the other unsubstantiated comments in this thread, I would assume as an airline they also brought modern security practices along with the rest of the deployment.
The interfaces between the avionics which held actual flight data and the IFE were read-only IIRC, and otherwise fairly isolated.
Yeah, I rolled my eyes too. That was so bad I just had to share.
Isn't this just great!
/sarcasm