Ask Slashdot: A Development Environment Still Usable In 25 Years Time?

pev writes: I'm working on an embedded project that will need to be maintainable for the next 25 years. This raises the interesting question of how this can be best supported. The obvious solution seems to be to use a VM that has a portable disk image that can be moved to any emulators in the future (the build environment is currently based around Ubuntu 14.04 LTS / x86_64) but how do you predict what vendors / hardware will be available in 25 years? Is anyone currently supporting software of a similar age that can share lessons learned from experience? Where do you choose to draw the line between handling likely issues and making things overly complicated?

Comments

Why not future proof the application?

[grimmjeeper]

Why do you need to ensure you can keep recompiling it with the same old compiler for the next 25 years? Why not design it with the expectation that the development environment will evolve? Ensure you design in portability between compilers and development platform operating systems and you don't have to keep stringing along an environment that's already obsolete.

Don't use an IDE

[Kinthelt]

C, make, and vi/EMACS.

Re:Don't use an IDE

[Anonymous Coward]

This is half of the answer. C and text editors will be around forever, However, the missing part is documentation. There will be stuff you have done that is built on assumptions. That must be documented. We can still maintain (and do maintain) 35+ year old aerospace code, and it's relatively easy *because* all of the software artifacts are still available. They've been ported now to 3 different formats, but we can still trace EVERY SINGLE LINE OF CODE to a requirements document, and each lower level requirements document to a higher level requirements document. All of the input assumptions and bounds checking are documented. Troubleshooting is done in requirements before in software, modifications are made in requirements before software, and debugging is pretty straightforward, as all of the unit tests are written straight from the requirements documents (to include bad inputs). We got a new engine sensor when the old one went DMS, not a problem to integrate it.

Just use FreeBSD, goddamn it.

[Anonymous Coward]

Goddamn it, why would you even suggest VMS when we have FreeBSD?

For over 20 years now FreeBSD has proven to be one of the most reliable and trustworthy operating systems out there.

Unlike VMS, FreeBSD is very widely used, is very modern, is undergoing continuous development and improvement, and is truly open source (unlike proprietary or GPLed software), while still retaining superb compatibility.

I'm confident that FreeBSD will be around in 25 years, and I'm confident that it will be as strong as ever then. It's much more resilient to problems like, say, systemd is, by the very nature of its project structure, the people involved, and their priorities.

I know I can trust FreeBSD. I can't say the same about pretty much every other operating system out there, with the exception of OpenBSD.

Re:OpenVMS

[Anonymous Coward]

Outdated... proven... mature... what's the difference?

Write A Support Agreement - Business, Not Tech

[brian.stinar]

Unless you are (or someone is) getting paid to update, maintain, and upgrade this frequently (I would suggest every six months) I do not believe this is something than can be easily accomplished. I would recommend, if you are a contractor, that you create an ongoing maintenance agreement that provides deployments tests every six months. If you are an employee, I'd recommend you attempt to put into place such a program with your employer.

If people do not want to pay to maintain this, then it's probably not going to work for 25 years despite your best efforts. If they only want to pay to maintain it when they REALLY need it to be maintained, it's going to be expensive and not necessarily possible. I see this kind of stuff all the time - customers don't want to pay to maintain something, until it breaks, then they want to pay.

As an example (that isn't related to embedded, but the principle is the same), I JUST ported over Google OpenID logging in to OAuth2 in a PHP system. This was way more expensive, and way higher stress, because the customer did not listen to me six months ago when I said Google would no longer be supporting OpenID, and we should migrate to OAuth2 or they wouldn't be able to login. They didn't listen to me then, but called me when they couldn't login. The hourly rate was higher, because I hadn't scheduled this work, and it took longer (billable time) because I was under pressure to get the calendar time as small as possible. However, we got it! There are examples all the time where things basically need to be scrapped, since the technology is so, so, old and the provider doesn't exist anymore. For example, I am having a lot of trouble finding documentation for CouchBase 1.0 on some CouchBase work a customer wants done.... This wouldn't have been an issue if they had kept upgrading CouchBase versions along the way. Now, it's a pain.

Re:wrong "obvious" solution

[MightyYar]

This is good advice. You want a whole bunch of other people to be in the same pickle as yourself. That means there is a market, and where there is a market there will be a vendor catering to very old system support.

Crystal Balls

[Tablizer]

If I could accurately predict 25 years out I'd currently be playing poker with Warren Buffett in a mansion instead of trolling Slashdot.

Be sure you don't have the 2038 bug

[DickBreath]

The 2038 problem is similar to Y2K but for Unix. 2015 + 25 years = 2040.