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.

Re:Why not future proof the application?

[danbob999]

Because not only the code would need to be portable, but the build system too (makefiles). Also, in 25 years you don't want to re-qualify everything and risk introducing some new bugs because the new compiler doesn't behave like the old one. Too risky.

Re:Why not future proof the application?

[Ungrounded Lightning]

if you have any sense whatsoever, you'll have a suite of regression tests to run on your software already. You can use that to validate the new environment when you compile a baseline. I've been involved with several projects that migrated from one platform to another.

Such tests might convince YOU (the developer). But would they convince REGULATORS? If not, you have to go through a whole, horribly-expensive, regulatory approval every time you migrate tool versions.

Regulators don't get dinged for insisting on more costly work by the regulated and withholding their approval. They DO get dinged if they approve something that then does harm.

That's why the FDA caused something like 400,000 extra deaths by delaying the approval of beta blockers for prevention of secondary heart attacks until the European research had been repeated in the US under US rules, rather than accepting the data and allowing the use. After the Thalidomide mess they're not going to approve ANYTHING quickly or easily. The same principle applies to other fields.

Don't use an IDE

[Kinthelt]

C, make, and vi/EMACS.

Re:OpenVMS

[danbob999]

Yeah, use something already outdated to make sure that no one evens remember it in 25 years.

IBM or VMs

[dmaul99]

If you're talking about IBM Mainframe stuff, then don't worry about it. IBM will support it in one way or another for the next 500 years because the systems that processes your airline reservations and processes your credit card transactions all still run on mainframes with COBOL code and CICS UIs. Nowadays they're dressed up with modern GUIs on top of it but ultimately it's all the same. Peek over at what the airline agent is looking at when she prints your ticket and you'll see a text console with lots of green and where you press CTRL to submit the form.

If you're talking about some modern unix or windows stuff, VMWare it now or something. In 25 years you'll have your quantum singularity computer with an emulator for GoogleOS 54 inside of which you can run an emulator for Windows 15 inside of which you can run an emulator for Windows 11 inside of which you can run VMWare Player with your stuff.

Better get started.

Re:IBM or VMs

[TWX]

Came here to say this. The financial system was implemented in the eighties on an i-Series and is written in COBOL and RPG. There are web front-ends for some components, others still use a "Client Access" TN5250 client or for me, since the console TN5250 client isn't being maintained for Linux anymore and doesn't want to compile, a 3270 client still works.

Do not overlook the service agreement/contract. Do not overlook the need for grizzled old guy with poor social skills to take care of it. Do not parade him around in front of senior management, they will hate him and it if you do. Make it clear that it's not DOS. We've seen people complain about the system because it was text-based, calling it DOS. They're fools, but if you don't nip that in the bud at the beginning it'll bite you in the ass later.

Also, define service windows when there is no expectation of access, and enforce them even when there's no maintenance from time to time, to keep people from complaining when there is a legitimate service needed. It's annoying but it can be necessary when some asshole thinks that they should work on something at 3am because they feel like it, even when that's in the middle of the published service window.

Re:OpenVMS

[Anonymous Coward]

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

wrong "obvious" solution

[rubycodez]

layers of complexity only increase the number of things you assume about the future.

Instead use a common realtime OS and chipset. Those already have a track record of decades of support.

Failing that the second best solution would be embedded java app.

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.

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:OpenVMS

[Anonymous Coward]

Why did the stupid parent comment get modded up to 5, Insightful?

There are huge differences between software that is outdated, software that is proven, and software that is mature.

Outdated software is old, and isn't being actively maintained. It's a fossil, frozen in time. See CP/M.

Outdated software isn't necessarily proven. It may have had stability problems in the past, and these were never fixed because the system was superseded with better technology. See Windows 95.

Mature software is independent of age. Newly-written software can mature quite rapidly, if developed using the proper techniques and by talented developers. See Dragonfly BSD.

Then there is software like FreeBSD, which is proven and mature, but not outdated.

If you can't comprehend the differences between these concepts, then you'd best be keeping your mouth shut, son.

Be sure you don't have the 2038 bug

[DickBreath]

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

Re:Store the hardware

[Tailhook]

Better plan: pick something that is currently and widely used in aerospace and military applications and the world will preserve working systems for you.

I have personal experience with this. 15 years ago, just before I left an employer I had worked for for some time, I took a number of Digital Alpha workstations off their hands; they just gave them away after about five years of use and replaced them with newer workstations.

It turns out there is a thriving market for this hardware because aerospace and military outfits used it for their work and today they still have drawings and material they need to deal with in original form. They have migrated the original material to newer systems, but they also still maintain the equipment and software needed to get at the material in its original form.

They pay through the nose to get replacement parts and complete systems in working condition, so a salvage market has emerged and people prowl around trying to find caches of ancient workstations. Doubtless this will be ongoing for at least another ten years, and the prices will escalate accordingly.

So if you need to ensure there will be spare parts and systems at your disposal a quarter century from now, find out what Lockheed and Boeing are designing today's jets with and use that stuff. It's built well and people pay dearly for it when new, so it tends to be carefully preserved; it's hard to trash something that cost $20k, even if it is wildly obsolete.