Node.js running in the new Airbus A350 inflight servers
reaktor.com
reaktor.com
* 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.
Yes, they are. Empirically ([1], just to name one example).
> Either way, C is best because it has both of those things (tooling, defined behavior).
C has tons of undefined behavior.
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.
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.
"undefined is not a function".
What makes the joke relevant to the discussion is that this is the first thought on lots of people's mind: "gee, I hope they don't ever use it for the actual flying system".
It sure was the first thought I had, even before seeing the parent's joke.
That's the second thought for me. The first was "thank goodness the airline I'm flying intercontinental with next week uses Boeing planes at that route".
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...
What's remarkable about HN is that most jokes are heavily voted down with responses like "go back to reddit", and jokers regularly complain that HN has no sense of humor. And yet every now and then a joke gets voted to the top. I've yet to wrap my mind around this phenomenon, personally...
People overestimate how different they are from the average person all the time, but regression to the mean is a thing. That's how we get a general culture (in the broad sense) -- even if there are subcultures within it.
Besides, how diverse is HN? If anything it's one of the more targeted communities -- most people here already are focused in programming and startups, and have a same-ish background even when from different countries. Contrast with something like YouTube or Reddit (general channels), where people are from all walks of life.
If 9gag, which also gets people from all around the world and with all kinds of interests and ages, can develop a "cumulative sense of humor" (and it has) then surely HN can too. This doesn't mean that everyone on HN will agree on some funny thing -- just that a large percentage will.
Someone deduced that it was the time that the comment was created that mattered. If a large number of jokesters are on at one point then their up votes will create the critical mass to push the comment to the top and keep it there.
I also believe that once a post is at the top fewer people will downvote it, either because they are afraid to go against popular opinion or merely respect it and leave it as it is.
"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.
Often when you review critical failures you find multiple things went wrong at once to cause the catastrophic failure. I would place a good bet that there was a failed fan, poorly secured heatsink or maybe just a clogged air filter that meant the hardware was unable to handle the additional heat being produced.
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.
Don't get me wrong though, I don't think that using JS in a plane is a bad idea. In fact I think the aviation industry is extremely slow moving and it frustrates me, fortunately the experimental category has access to some interesting tools but for certified aircraft you're very restricted in what you can and cannot do to modify the aircraft.
I'm not sure I understand this. Can't you get a backtrace out of a JavaScript exception just as well as you can get one out of a segfault? The segfault itself doesn't carry any information other than at best the faulting instruction and the nature of the fault, and you can surely get that out of a JavaScript exception.
Furthermore, a segfault is very often a sign of memory corruption that has already happened, possibly in the stack frames themselves. "undefined is not a function" is not. JS code that crashes with that error is in a much more debuggable state than native code that crashes with a segfault. And you can certainly configure your interpreter to take a coredump on an uncaught JS exception, which will definitely be more debuggable than a coredump post-memory corruption.
(Your personal attack is not an argument.)
To clarify what I was trying to convey, the issue I personally find is that JS errors often produce difficult to understand descriptions and misleading traces when compared to some alternative languages.
I do believe that there is good work being done to convert these errors into more usable alternatives. Just recently I caught a glimpse of this: https://plus.google.com/+AddyOsmani/posts/DdWkiKsvbA2
Segmentation faults can also be very cryptic, especially in the memory related cases like you suggested, but its likely that any tool would behave in fairly unpredictable ways when it comes to any form of corruption or out of memory scenario.
Sorry again and hopefully that clarifies my thoughts.
Get off your high horse. What a ridiculous and ignorant comment.
I know it's a joke, but still: the in-flight entertainment system doesn't log to the flight data recorder.
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.
* in-flight entertainment system devs allowed to run
open source
* system is "online" via aircrafts satellite
internet connection
* devs pushed fixes mid-flight
(Edit: The article headline is Aircraft customer experience on a new level)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.
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.
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.
Anyway, I'm surprised they opted for a single threaded, non preemptive system.
Well, they should be, but apparently they are not:
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...
Whatever you could conclude from that article the bug bounty clause ruling those systems out would suggest they are indeed connected, as does the FBI statement (which appears to have taken a part of the conversation out of context but is in fact later on verified by the wired people as having some basis in fact, other than that the guy did not actually control the aircraft he should not have been able to get as far as he did).
I agree with you those connections really should not exist but there seem to be at least some wires bridging the air-gap, maybe read only, maybe not depending on the kind of plane.
Fortunately there appear to be enough safeguards in place to limit the damage that could be done and from what I understand these have held up. It also seems that the 'hacker' is a bit of a bragger but he got in a lot further than they initially gave him credit for, and in a way that is so simple that it makes you wonder what else they missed. The safeguards now seem to hinge on knowing what commands to issue and how to bypass authentication but that is stuff we see in an internet context on a daily basis so that seems to be - to me at least - very thin ice to skate on.
An airgap would be better and simpler.
Enfin, they presumably know what they're doing, personally I'd prefer for such a bridge to simply not exist.
If he had not made these stupid claims it would not have made me feel any better about all this.
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.
Extremely ugly first day prototype of that plasma cutter controller, the VIA board sits in the hard drive enclosure on the right hand side, you can just about make it out.
What did you build?
https://www.youtube.com/watch?v=dAyBz8XIMsU
http://www.silverball.net/images_martin/tech_pc_case.jpg
It was a MediaGX 5520 (233Mhz) motherboard with a custom PCI board holding an array of 8mbit ROMs + flash memory and a DSP for sound playback. Douglas Comer's XINU was used as an operating system and ran from ROM.
The "too early for it's time" was less about the pinball machine and more about the MediaGX. A small Geode board + Linux could have been a really nice platform. I think a lot of ATMs are actually using this formula.
I've worked on some coin op stuff as well but more video game oriented. The original software ran on Windows, I did a linux port to show that 'it could be done' without windows. The hardest part was to switch from one game to another (multi game console) without a video mode reset.
Another application for that board is on-board computer for cars. I've got a very similar board in a nice little case that just fits under the passenger seat and wires into the car by running cables to the side of the transmission tunnel. Boot times are short (runs off a flash disk) and media are stored on a small 2.5" hard drive. I like these little systems.
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.
;).
Neither of those have SloppyDevTypeCheckComfortBlankie either, do they?
The interfaces between the avionics which held actual flight data and the IFE were read-only IIRC, and otherwise fairly isolated.
I'm surprised nobody mentioned the Atwood's Law yet.
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
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.
Yeah, I rolled my eyes too. That was so bad I just had to share.
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.
Isn't this just great!
/sarcasm
Why couldn't they use Scala instead?
Wired article related to this:
http://www.wired.com/2015/05/possible-passengers-hack-commer...
States that there is a connection but it is supposedly one-way only. So no airgap. The article then goes on to note that a 777 uses a two-way bus but requires further authentication.
The sources are dubious (wired and telegraph). Experts quoted in the article claim its impossible, including the lead engineer of the boeing thrust management system:
> Whether it’s possible to create this condition by issuing a command from a passenger seat is a different matter, however. Soucie and others who WIRED spoke to agree with Boeing that this isn’t possible. But unlike Boeing, they provided clearer details explaining why. > >Peter Lemme, who was a lead engineer on Boeing’s thrust-management system for eight years until 1989, says the system provides the auto-throttle function that actually controls the engine thrust, and doesn’t allow the throttles for the engines to operate independently of one another.
You claim it's been "proven not to be the case". Extraordinary claims require extraordinary evidence. So far I've seen nothing from this Roberts guy. Sounds like he's just full of shit.
"A connection between the avionics system and the IFE does exist. But there’s a caveat.
Soucie and Lemme say the connection allows for one-way data communication only. The systems are connected through an ARINC 429 data bus that feeds information from the avionics to the IFE about the plane’s latitude, longitude and speed. The IFE uses this to populate the animated map passenger’s can use to track the plane’s movement.
“On every airplane it’s done a little differently and is done in a proprietary way,” Lemme says. But in each case, the ARINC 429 is an output-only hub that allows data to flow out from the avionics system but not back to it, he says. To talk back would require a second input bus. “I can’t think of why there would ever be an interface like this. If it’s out there, I haven’t heard of it.”
This would seem to be what Boeing was describing in its statement when it said that although inflight systems “receive position data and have communication links” to other systems on the plane, they are “isolated” from systems that perform critical functions."
So there is a link.
An airgap simply means this: the two systems are not connected. Not in any way, no physical connection exists between the two and any output from the one goes through an optical bridge into the other.
The only way air-gapped systems are possibly connected is via power rails but presumably those do not carry data nor do they have the possibility to do so.
https://en.wikipedia.org/wiki/ARINC_429
Suggests it is an electrical bus, not optically insulated.
If it was not extremely obvious that such an influence cannot exist with the law of physics that we understand, an investigation would be ongoing. The word “investigation” does not appear in the WIRED article, and “investigators” in the Telegraph article only refers to FBI.
The FBI is not qualified to tell whether an aircraft is so obviously immune to the defects that Roberts claim to have exploited that the investigation is an open-and-shut case. They don't like it when people plug into things they aren't supposed to plug into, and this is what they are accusing him of.
Call me paranoid.
That this guy was able to access the system at all is already quite a surprise.