Slashdot Mirror
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?
It's been around for almost 40 years and most trains and lots of factories are still running on it.
It runs on almost everything since the original hardware has been discontinued years ago.
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.
Keep a working system in storage for future use along with copies of software that runs on it including OS, etc., on archival disks.
C, make, and vi/EMACS.
"Evil will always triumph over good, because good is dumb." - Dark Helmet (Spaceballs)
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.
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.
Since all code will be written in Apple's amazing revolutionary innovative new Swift language, just write it in that! It will be infinitely portable and recompileable for millennia!
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.
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.
Linux is at the heart of many embedded devices, most smartphones, and a whole crapload of servers. Given the staying power of golden oldies like COBOL running on mainframes (or virtualized mainframes), I don't think that there is any doubt that the Linux kernel will be around.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Stick with command line utilities. Make and compiler on the command line have been around forever. Avoid IDEs with opaque 'project' files and do not let any sort of automake or autoconfig anywhere near it. Keep your Makefile simple and to the point.
Thaty way, at least you have the worst-case option of porting forward to a new build system should all else fail. THEN archive the whole thing inside a VM. Use raw disk images rather than a proprietary something that may or may not be supported 25 years from now.
I use Pacific C compiler from inside DOSbox to patch an 80188 SBC (single board computer). Seems to work fine, and it's 20 years old.
I think as long as your VM doesn't depend too much on IPv4 or being connected to the internet in general, it should be OK. I think equally important to having a VM is posting how to setup and install it, in the most brain dead and step-by-step way imaginable (screen shots for every step if you have to). Because it's really easy to forget that stuff over 20 years.
“Common sense is not so common.” — Voltaire
Deeply embed the tools required in the device itself. As long as the box exists, the tools exist.
Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
/. just ran this article about an Amiga still being used to control HVAC at multiple public schools after nearly 30 years: http://tech.slashdot.org/story...
Technology embeds itself (so to speak); it is far harder to retire old tech (as per this article) than you might think (Windows 8/8.1 just barely passed up WinXP this year). I think that Linux + C makes as much sense as anything, especially for an embedded system, and I'll cheerfully bet that both will still be around and in active use in 25 years. ..bruce..
Bruce F. Webster (brucefwebster.com)
If I could accurately predict 25 years out I'd currently be playing poker with Warren Buffett in a mansion instead of trolling Slashdot.
Table-ized A.I.
Take a look at Forth. Can run on anything and worst case, you can roll you own.
The 2038 problem is similar to Y2K but for Unix. 2015 + 25 years = 2040.
I'll see your senator, and I'll raise you two judges.
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?
[emphasis mine]
maintainable for the next 25 years...use a VM
Some people are answering how to make something "compilable" 25 years in the future. That's different from making it "maintainable." A VM will make the project compilable. But it won't make it maintainable. Ex: I can compile MS COBOL code for CP/M, but I can't find developers to maintain it. The only way to make it maintainable is to continue to update to newer operating systems, libraries, and tools over the course of the 25 years. If you are in a regulated environment, there is cost to that. That cost needs to be part of the maintenance budget for years to come.
how do you predict what vendors / hardware will be available in 25 years?
That is impossible. If management wants you to do this, ask them what the budget will be in 25 years. You can accurately predict the development environment in 25 years with the same accuracy that they can predict the budget in 25 years. The closest you can get to this goal, is to have the source code for everything. When you use closed-source software, then your contracts should require that the source code be released to you when the product is no longer supported. Such conditions are not uncommon in the medical industry. The contract will likely forbid you from using that source code for anything other than maintaining that product since they won't want you become a competitor.
I work for a medical device manufacturer, who does this. We do *not* try to predict what tools will be available in the future. We keep VMs and make sure it doesn't require external packages to run. Ex: all installs, binaries, etc. are available. No npm or nuget required on the build server. Over the course of decades, you will have to move the source into newer repositories (RCS -> CVS -> subversion -> GIT) or keep ZIP file archives since that is easier.