Hacker News Reader

Comment by dehrmann | Hacker News Reader

This got me wondering...if you were building out a system like this today, which OS would you choose that wouldn't seem ridiculous 30 year later? And why aren't we building OSes that are simple and feature-poor with the intention that they'll be used for 30 years? Or the airline problem: it must be annoying that the tech you put in seatbacks has a short shelf life and will look primitive compared to the phones in everyone's pockets.

View on HN

Whichever open source system best fits the usecase. There are a number of FOSS systems specifically for embedded real time systems, for general purpose stuff I'd probably go with OpenBSD. The key is not being tied to the vendor of the software. You want to be able to hire a bunch of random programmers in forty years who can just look at the code and port it to whatever hardware is cheap at that time. Ideally you'll want to continuously have a small number of people working on keeping the system running on recent hardware and updating the dependencies.

Take it from the other direction: What could you have chosen in 1989 that wouldn't seem ridiculous today?

How many OS releases from 30 years ago still have commercial support? How many OS releases from today can still run a binary from 30 years ago? Will the 30 y/o toolchain still work? Will the most recent release of the toolchain be able to compile 30 y/o code? Do you still have all of that 30 y/o code? Are there other dependencies? Can it run on modern hardware or is it readily emulated / virtualized? Is talent with the necessary experience still available in the workforce?

Looking back is pretty bleak and I don't think it's any better looking ahead. Technology is a liability.

The seatback device is a consumer electronic that can (and should) be experimented with, updated, upgraded, and replaced regularly. I don't care what OS it is using today or how fancy it looks - that has nothing to do with the first part of your question, which should (and fortunately usually is) altogether separate.

The off-the-shelf answer today is a variant of QNX or VxWorks. No one gets fired for picking those.

I thought most seatbacks ran Linux?

For more critical applications, Boeing is using Ada on Linux atop AMD's new embedded CPUs, which have no closed firmware (to ensure auditability).

Sadly, Boeings culture rot has led to some poor design decisions recently.

I am yet to see any Linux distribution certified for high integrity computing.

Usually Linux always runs in a VM sandbox on top of such OSes, like Green Hills INTEGRITY OS.

pjmlp is right: life-critical software must be certified to high levels of DO-178C standard. That's always either custom software or some RTOS's that are certified already. Linux couldn't pass DO-178C's high levels, if at all. The INTEGRITY-178B page has the docs and processes listed in bottom right if you want to see them. That's for prior standard, though. New one looks similar.

https://www.ghs.com/products/safety_critical/integrity-do-17...

They probably run Linux in the less-critical stuff on the plane. At one point, they were running some apps on Windows and Linux simultaneously as a reliability technique. I don't know if they still do that.

Yes, but I wasn't talking about the seatback devices ;)

> This got me wondering...if you were building out a system like this today, which OS would you choose that wouldn't seem ridiculous 30 year later?

I'd probably use GNU/Linux, but build it in a fashion that make it easy to swap components (either hardware or software) as needed.

RHEL/Ubuntu/Debian LTS and pray enough people remember how to work on it.

Or don't let your software get 30 years old. Reduce the number of components required to run it (avoid complex toolchains) so that when upgrade/porting time comes, there are fewer things to break.

Reply on news.ycombinator.com