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)
I mean emacs
You're trying to create a VM with all of the tools for your development environment which will last 25 years.
Why start worrying about being overly complicated now?
Lost at C:>. Found at C.
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!
Try taking your install and making it into a bootable iso image and a bootable DVD. Run off of that.
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.
A friend of mine heard a talk about a guy to had a similar problem in the airline industry. He needed the whole hardware and software package to be maintainable for 80 years. He used Field Programmable Gate Arrays: https://en.wikipedia.org/wiki/...
I've been a user of Linux since the early days of Yggdrasil, and I still use it today. I've never been as uncertain about the future of the Linux kernel as I am right now. All of the major Linux distros have switched to systemd. Systemd is handling more and more functionality every day. I would not be at all surprised if it starts to subsume more and more of the Linux kernel's functionality. The Linux kernel will eventually be nothing more than a second-stage bootloader, at which point it starts to become very irrelevant. I could easily see the Linux kernel being discarded in favor of systemd.
25 years is a long time from now. I don't see how we can ponder what things will be like then when it's very possible that so much of today's important software, like the Linux kernel, won't even be relevant in as soon as 5 years.
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.
You appear to be in the UK, so I'll suggest you check with the Ministry of Defence and get a list of UK defence manufacturers that build software-intensive systems with long life cycles. You're looking for things like airplanes and boats. Then write a NICE letter to those manufacturers and ask them how they do it.
The military routinely deals in systems with very long life cycles and many software upgrades.
As one example, the American F-16 first flew in the late 1970s. It is expected to continue to fly well into the 2020s. That's half a century.
The American B-52 first flew in 1952. They're STILL flying, and it is not unusual for a pilot to fly the same airplane his grandfather flew. (Flying his father's airplane is routine.)
You might also consider querying NASA in the US. They routinely launch deep-space missions that will take years, even decades, to reach their destination, and require software upgrades while in flight. For obvious reasons, it is not feasible to upgrade or replace the hardware on a probe out around Saturn's orbit, while it is on its way to Neptune.
The obvious solution is to build 2-3 boxes with the software needed to maintain your package, set them aside, and leave them the hell alone.
Compared to the hassle and costs of trying to figure out obscure bugs caused by compiler/IDE/platform updates, it's the cheapest option you've got.
Did you not notice the recent article about a school district's HVAC system still running on a long-obsolete Commodore Amiga?
Have you never read about NASA stockpiling Intel processors of bygone eras for maintaining their fleet of hardware?
In short, are you completely incapable of learning your lessons from what people have already done for 50-odd years of computing?
I do not fail; I succeed at finding out what does not work.
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.
1) Design the processes involved independently of the language/tool/platform to run them.
...
2) Choose a very stable platform, as the POSIX one (you already work on Ubuntu anyway).
3) Be modular.
4) Use a standards compliant language. They evolve very slowly but also, they are available for longer periods of time.
5) Do good technical documentation and keep it updated.
The (1) will permit you to design things that could last for centuries. Take into consideration how people control the ships on the sea; they use protocols having more than one thousand years by now. Today have computers, but this is not really a must and they know what to do when the computers fail.
The (2) let you migrate from old hardware to new one without loosing compatibility. Yesterday these systems were using IDE disks, today SATA or SSD and tomorrow who knows? This is not something relevant when you don't think at that level, and the new POSIX systems have drivers for the new stuff, you just store and retrieve data using the standard primitives.
The (3) is a must. You can replace modules when you have better options. If everything is a big monster, forget that you will keep it running without an issue for so many years.
And the (4) offers you a quiet evolution. You could be using K&R C, and to work with C11 these days. If your design is good enough, your software won't be legacy and the only you need to do is to recompile and, maybe, to replace some small pieces that become obsolete with the years.
The (5) is a big problem in almost all software around. People are accustomed to work quickly and to not to describe what and why the did the things. Ten years later, even the original programmers forgot the details, what could be expected 25 years later? a miracle?. So, document, document, enforce it, check it
This is the type of question that calls out of the basement all the Emacs and Vi nerds, and bring the associated editor wars with them.
REMOVE THIS POST BEFORE ALL HELL BREAKS LOSE!
Put it in a chroot setup.
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.
It's probably some certified environment - you can't use plug in newer versions of tools without having to go through a full recertification process.
This is common for safety critical applications (for example).
Why build in the cost of such a requirement? Have you attempted to cost an entire replacement? Is it that much more? Do you need to move to market now, or are you able to wait for this requirement to be "satisfied"?
/. 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)
Linux is already being replaced by Pottering OS, so don't count on it being around.
Depending on the regulations attached to your specific industry and how your company chooses to cope with them, "being able to maintain the application" may not be sufficient. If something goes sufficiently pear-shaped to get a government agency involved, they may demand that you be able to produce not just the source code used to create any given release, but the combined libraries, toolchains, etc.
Hell, you *MAY* even be required to completely and faithfully recreate your entire development environment as it was on the date of sign-off. Only really feasible way, imho, to ensure that you can comply with that sort of a request is if you were to do all of your development inside a VM and take a snapshot when each release is blessed. (or at any other milestone)
What about the old fachioned way:
Ensure that the physical hardware that you are going to use to run your development tools on will be available as surplus for the service life of your system. Have at least one backup machine any time for quick swap on hardware failure, maintain multiple copies of all your software which you refresh periodically.
I think x86 wont be a bad choise, and Iäm fairly sure you can buy DVD's in 25 years from now. x86 is about at its end of life now, so what ever you buy in the next 25 years, will most likely be from this time period.
About 20 years ago, I accidentally solved a similar problem. I created a Windows application using Visual Studio with MFC without thinking very far into the future. It turns out that I still maintain that application - and a few spinoffs of it - to this day. VS and MFC turned out to be a good choice for this system.
I've had to do some migration work every few years as newer versions of VS came out, but that's been tolerable. For example, I recently migrated from VS 2003 to VS 2010 because 2003 doesn't run correctly on Windows 7. And I recently made a transition to Unicode, which was slightly painful but tolerable - definitely the right thing to do at this point.
VS may not actually be the best answer to the question, but my experience does illustrate a few points. It worked for me because:
- The IDE had a large user base and ran on a ubiquitous platform.
- The framework, MFC, likewise has a large user base. Microsoft doesn't seem to care much about MFC anymore, but it's easy for them to maintain with each new version of VS. Basically, as long as VS, C++, and the Win32 API is around, it makes sense for them to update MFC whenever they update VS. Typically, they just add new features for new API things I don't use like the "Ribbon" interface. That's easy enough for me to ignore.
- Migrating to the new version of the system every few years makes sense. I don't do this with every version of VS, but I do it with every 2 or 3. Microsoft more-or-less forced me to do this when old versions of VS would no longer run, but it's actually been good for me overall. However, if I had somehow managed to continually use VS as it existed 20 years, the pain of migrating to a modern version today might be too great.
I have maintained various legacy systems dating as far back as the late 1970s some have faired better than others. By far the biggest difference between those that faired well and those that didn't was continuous supoort. A system from 1990 that wasn't maintained for only a few years due to the false assumption it was being phased was much harder to maintain and than older system which never went out of maintainance.
The popular technilogies faired better than the trendy ones. PL1 Cobol and later C all faired well. Ada not so much. IBM mainframe faired very well. Nonstop servers (HP) not so much. Binary only libraries prevented hardware upgrades even when almost everything compiled properly. If you stick to the popular now yet mature technologies you won't be alone with your troubles down the road.
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.
Presumably the target embedded system isn't running Ubuntu. So really all you need is some way to keep the compiler/linker running - the rest of the build environment is irrelevant. Unless, as mentioned above, everything has to be certified - in that case then what you need is several complete dev systems on a shelf somewhere and pray that you don't use them all up.
See also the story about the Amiga HVAC controller which someone else already linked to...
If the system is expected to run for 25 years, then it should still be able to run its own compiler in 25 years too. As long as it's not underpowered, it should be able to build its own software. So do the development that way too. Although I do wonder if flash storage is up to a 25-year lifespan.
You're just dead wrong. Trying to throw it away and starting over is very, very expensive. Hell, even in industry, most code refactoring projects fail miserably. In the aerospace industry, you have to recertify the entire aircraft if you throw away a significant piece and start over.
What you're missing about the aerospace industry is that all software is written with a rigorous design process that starts from high level requirements documents and is designed on paper long before any code is written. We routinely have the unit tests written before we start writing the software. There's no need to scrap anything except hardware that's gone DMS. And, getting new hardware, compiling and testing is fairly straightforward with a good design. Our biggest problem is that processors keep adding registers, so we have to add more to the tests to compensate for the additional failure modes that more complex processors bring. However, we're still using Freescale 683xx processors because they still work, and the code we've ported to ARM ported very cleanly, though ARM doesn't have a proper real memory mode.
Take a look at Forth. Can run on anything and worst case, you can roll you own.
FORTRAN! GPS is STILL written in FORTRAN. It will outlive the cockroaches!
1) Keep redundant hardware examples around and make sure your backups are copied to new media frequently enough that you don't lose data,
or, as some have already suggested without saying these exact words:
2) give it up. That is, plan for the development environment to change out from under you.
In the simplest cases, such as running a 16-bit DOS application you wrote in 1990, it may be as simple as finding a modern-ish computer than can boot with an error-free copy of your 1990 DOS 4.0 + Borland Turbo C development environment hard disk and hope that the newfangled UEFI and post-80486-chip and modern chipsets doesn't break your code. Bonus points if your code didn't use any Borland-specific, DOS-specific, or hardware-specific extensions or libraries so it can compile under any modern C compiler on any machine.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Look at stuff that existed 25 years ago that still exists and is supportable today. That will give you an idea of the *sorts* of things that could be supportable in 25 years.
Well, here's a development environment that is still quite usable after 17 years. I'm talking about Visual C++ 6.0. If it still works 8 years later, than I guess it fits the criteria.
Well, I'm supporting some hardware/software systems that go back to the 70's (45 years). I'm afraid I don't have much encouraging to say though.
The nice thing about PDP-11's is that they were relatively ubiquitous, so there are lots of folks out there offering emulators, and even some with PDP-11's on a PCI card. The biggest problem we've had is with getting access to old sources. Source control discipline wasn't that hot back then, and a lot of the code was just done in machine language. Even if we had the sources to that, there aren't exactly a lot of folks conversant in it still working today. Plus a lot of the stuff still stuck there is stuck there because of hardware dependencies. For example, we had one networking protocol that goes back to somebody's decision to use the PDP-11 printer port for networking. Nobody ever tried upgrading both sides at once, so we stuck using this historical oddity in our system through several "upgrades" on both sides of the link. Its not so easy to find cards for this anymore when another single-side "upgrade" comes along.
On the plus side, a lot of our older stuff runs on some company's personal flavor of Unix, so the ubiquity of Linux for ports to modern hardware has been a huge boon for modern ports. So if past history is any guide, I'd highly recommend targeting Unix.
I still maintain a group of embedded semi-smart terminals that run OSes from MSDOS to current versions of Windows. The original program was written in Turbo Pascal 7 back in the early 90's, and some of the old ODS boxes are still in use.
The program has been updated over the years to run on Delphi and now XE2. Three or four different development environments, but they can all be convinced to run under Win 7/8 (I haven't tried Win 10 yet.) I see no reason to expect that they won't live on long after I am retired.
I first thought it was "Still Unstable In 25 Years Time?" and wondered how the developer failed to notice Windows..
The right questions are:
1. What is the service life of the products I'm developing?
2. What are the maintenance requirements, risks and costs over the lifetime of the product?
A development environment is only small part of the maintenance plan.
Looks like the OP is hoping for it to crash in 2038 and it planning on coming out of retirement for big bucks.
Linux is already being replaced by Pottering OS, so don't count on it being around.
Not to worry. A special delivery via drone is coming to L. Pottering that will give new meaning to the term surgical strike. Debian GNU/Linux was my preferred distribution but with the decision to incorporate systemd there seems no choice except to roll my own distribution. The really sad thing about GNU/Linux in general these days is the bloating of the kernel and the constant additions instead of focusing on streamlining it and removing unused variables and code.
Long story. Longer, in a sense, than 35 years. But this was a big one; windowed graphical user interfaces, context menus, mice, object oriented programming, ethernet.
Started with Smalltalk, and the Learning Research Group at Xerox PARC. Hasn't ended.
It's called Squeak now. Squeak's VM is written in a subset of Squeak and then automatically translated to C. So it's relatively easy to port to other platforms, as long as other platforms have at least a 32-bit word. It's not back-compatible with the original 16-bit Smalltalk-80, but it's forward compatible with anything you want to put a little effort into, and runs on almost everything already, with bit-identical, pixel-identical, write once and *really* run everywhere portability. Full integrated development environment and graphical user interface.
The language doesn't suck either. Nice mix of wild west mutable objects and functional ways of dealing with collections. Closures. Continuations.
There are other languages that can do this stuff, but none of them are as balanced, complete, and portable as Smalltalk.
Links:
https://en.wikipedia.org/wiki/Smalltalk
https://en.wikipedia.org/?title=Squeak
Cheers,
--C
Then why isn't your build system written in the same language?
If I'm writing firmware for a microcontroller based on the MOS Technology 6502 architecture, I don't especially think writing the build system in 6502 assembly would be the best choice. That's why I use mostly Make and Python for my 6502 projects.
There, done. Use standard C, C++. Fortran or what ever and standard libraries. And don't buyinto the "modern" software hype. I can still compile and run the software I wrote in high school in fifteen minutes after I install a machine. Software written for IIS/MSSQL/MFC in the 2000s? Not so easy...
Maybe it'll be released by then?
(I don't know anything about perl, but someone had to say it.)
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?
Realistically how long would it take for the vendor to go out of business, then how long until you can't find the hardware to run the last version on? And I'm sure there'll be migration options for any semi-popular virtualization system. Worst case you might want to save the install instructions (iso of OS + whatever else you've loaded on top) to use with a different VM provider. No doubt x86_64 emulation will be around 25 years from now, no matter what we run on. You're making a mountain out of a mole hill.
Live today, because you never know what tomorrow brings
There is a crapload of AS400's out there still running the accounting for very large companies and medium sized companies.
There is a crapton of 25+ year old environments that still have software being developed for them and or need it.
Hell I was looking for an AS400 with a full software loadout on it after I learned what my wife's work pays for their expert per hour. I'll take $225 an hour any day.
Do not look at laser with remaining good eye.
Haven't you heard? Visual Basic is the wave of the future, everything else will pale in comparison!
Just cruising through this digital world at 33 1/3 rpm...
The inventors of Unix would be at home in my development environment: Bourne shell, vi(m), make. Unchanged for 30 years, still going strong. Consider that it was used to develop Ubuntu 14.04 LTS.
The submitter doesn't really provide enough information to fully answer the question. What software tools are needed for this embedded system? What hardware tools (debuggers, programmers) are needed? Does the development system need to be qualified by some sort of regulatory agency or are they free to upgrade tools as needed? How do they plan to staff the engineering team for 25 years?
If you built an embedded system using a MIPS CPU 25 years ago, you might not be using the same hardware or OS for development, but if you used GCC, you'd probably be using newer versions of the same build tools to compile the software. You might be using Eclipse instead of Emacs to maintain the software, but the same Makefile scripts could still be used to build it.
Avoid vendor extensions to languages or tools at all costs, such as GCC-isms or VC-isms. Use only standard language constructs. About the only answer I can give you is "rely on open source tools that have stood the test of time." And rely on the same tools and platforms that others developing long-term maintainable systems are relying on. That way there is shared incentive to keep the systems functional through time.
Consider the IBM Power Systems, formerly known as the IBM System i, AS/400 and eServer iSeries.
The systems in these product lines are intended to be in use indefinitely with a completely compatible upgrade path. The operating systems and the software used on these servers are based on an architecture that has been in continuous use since 1979, the System/38, and the software that runs on these systems has been in use even earlier than that.
https://en.wikipedia.org/wiki/...
Kriston
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.
You KNOW it won't change... Just be sure to buy a bunch of hardware for it to run on. Don't worry, it will be CHEAP hardware so you can stockpile a couple of systems for each year of your presumed project lifetime for next to nothing. Just make them identical, buy 50-75 of them, and shove them into storage.
Then, when you get down to about 10 copies of the development hardware, start thinking about re-hosting it onto something else.
The digital preservation community in libraries (when archiving software) has to deal with a lot of these aspects.
I'd recommend learning about https://en.wikipedia.org/wiki/Digital_preservation, plus documenting your project with appropriate metadata in the right formats, e.g. http://www.loc.gov/standards/premis/.
If you've got lots of artifacts (e.g. documentation) that need to be maintained with it, learn about OAIS (Open Archival Information System) and compatible systems. It was developed by a consortium of space agencies for long term storage and retrieval of maintenance documentation, etc. Now in common use for digital asset management in many cultural heritage institutions too.
C/Fortran 2003+ on a Unix, posix compliant, platform running some sort of X-Windows windowing system. All tried, true, usable, good for embedded systems, and portable.
Avoid anything buzz wordy. No XML, too bloated for an embedded system. Avoid anything proprietary or requires a huge library stack. If you need persistence use something lightweight and sane like MySQL or Postgresql. Scripting languages with perhaps the exception of Perl or bash are probably too bloated as is anything that must run on a Java VM.
Use lowest common denominator ASCII text.
That's how I would approach it.
putting the 'B' in LGBTQ+
In 2001, I wrote a service in Java 1.3 and Oracle 8i, and set up a Windows XP VM to compile and run it on. 15 years later, I am still able to launch the VM and do maintenance, and expect that 11 years from now I will still be able to. 25 years is not that long as it sounds at first...
Emacs isn't an IDE. It's an OS. The only thing it lacks is a decent text editor...
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
It seems to me that you have already figured it out.
Get a developer/build VM Image and you're basically done.
Well, that and make sure to use open source / easily licensed tools so you won't ever run out of a license.
Are you worried that the x64 instruction set is going to disappear within the next 25 years?
I'd say that is highly unlikely.
When AMD when to x64, they made sure it still ran x86.
In 25 years, I doubt we'll be dropping x64 from mainstream support. You're probably safe there.
Not to mention, you'll probably be able to buy some old chips if that should ever happen. Just go on ebay and you can still find 386 chips :P
Not to mention virtualization.
I'm morbidly fascinated with this concept of systemd subsuming the kernel too.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Submitter said Embedded Project. So Minix could be a better choice for what he wants
Maybe systemd could be a microkernel like Minix, w/ all the various systemd services at the periphery. In fact, you could then start using the various rings of the CPU. Ring 0 for maybe a hypervisor, Ring 1 for the systemd microkernel, Ring 2 for the various systemd services and Ring 3 for all of Userland.
Not sure how well BIOS emulation under UEFI is working, but if it does it should be very easy to run DOS.
Inevitably it will be labeled as 100% compatible but it will have a but that makes it useless for your application, and the bug will not be detected until the worst possible moment.
Until about five years ago I supported a custom application running on CP/M. I just kept some spare hardware so that if anything broke I could swap it out, and I also could use the spare parts for developing on. Not that I actually did any development for the last fifteen years of the contract, all I did was visit once a year to blow the dust bunnies out.
What really matters more in maintaining software across multiple generations of hardware is the fundamental design of the software. Well designed, structured code can be 'ported' to new languages and environments. My company has been maintaining the same application (with significant enhancement) for over 30 years, on new OSes and hardware. Started MSDOS, currently HTML/PHP/JS/C.
OpenVMS has nothing on the IBM 370.
C and a Makefile.
...why does an OS "expire?" The only reason we spin OS releases as fast as we do today is for (a) new hardware support/bugfixes, and (b) security hole fixes. If your critical long-term project is air-gapped or ROM-based, why would it need patching?
Having the OS and all of the tools packaged up as a bootable VMware image is a great idea. It removes all of the issues about how to resurrect it later.
I can't image VMware removing backward compatibility (or failing to have tools to provide the ability to move things forward). Just in case, I see two solutions:
1. Fire up your VM once a year with whatever you are using to run VMware VMs and do a forward-compatibility upgrade if available to be sure you don't fall too far behind.
2. There are cloud providers who want to provide space for your VM. They are likely to have a forward-compatibility plan for their customers, even if those customers are so "lightweight" they are essentially non-paying.
Omne ignotum pro magnifico.
CICS debuted in the late 1960s and keeps getting more popular and modern. The key, though, is that IBM doesn't break stuff, and that the invested value in CICS application code keeps increasing. Its baby brother is called TXSeries, and there are even companies that have implemented TX/CICS clones (though I'd stick with the genuine article). If you stick to TXSeries APIs (for the abstraction) your program will run (and continue to run) on both TXSeries and CICS Transaction Server. Pick any durable programming language -- C, COBOL, or Java, probably -- and you're OK for at least a quarter century (and more like half a century) with high confidence. Use CICS/TX facilities/abstraction for data access. If that needs to be relational, DB2 is a good choice underneath, though keep the SQL vocabulary very "plain vanilla" if possible.
Nobody has supported durable, long-term application environments like IBM, and nobody else is likely to for the next quarter century plus. CICS and TX are the preeminent examples and even more relevant today than they ever were in that role.
10 REM HELLO WORLD
My first Linux install was Yggdrasil on a 386SX! I installed it to help with my Computer Science homework!
Actually...25 years ago was 1990. Windows 3.0 had just come out.
I worked on a project once that used three programming languages. All three of them had gone through incompatibility-causing changes by the end of the project, and that in a space of three years. One was C; it went from 16 bits to 32 (which should tell you when this was). Since I was doing things that depended on the size of int (I was using ints--or maybe it was long ints--to encode things at the bit level), that was relevant. That would not have been too hard to fix. The second language was Prolog; the version I used also transitioned to 32 bits, and the vendor decided at the same time to change the way C calls were made. That would have been more difficult to change in my code. The third language was Smalltalk; the vendor was bought out by its competitor, who had an incompatible version. The version we used was dumped. That would have been a nearly complete re-write.
As a result, my next project encoded its information in XML, and I wrote a converter (in Python) to translate the XML to the programming language of a finite state transducer. When (not if) that transducer becomes obsolete, we'll change the converter. (Of course Python may go out in 25 years, but the converter is the simple part.) I do not expect XML to go obsolete soon, and when it does, at least the data is human-readable (and there will probably be a converter to whatever the replacement for XML is).
1. Document the I/O for the system, so it can be replaced if necessary. Have someone rebuild the system using this documentation to check and revise it.
2. Document everything you code, as You code it, and update the documentation. Then give the documentation to someone else and have them code it. Update the documentation as they ask you about it. Leave that documentation so they can totally rewrite the application if necessary.
3. Use common chips that were available 10 years ago. Avoid fancy all-in-one H-Bridge chips. Leave behind tested schematics and PCB layouts. Document every chip in detail.
4. Leave a FOSS development environment on disk. It should be on multiple media (e.g., USB flash dive, SATA SSD, SD Card, etc.) Keep the code on separate media, so that a future idiot will not have trouble with losing the code or getting confused as to which version is usable.
It is acceptable to virtualize this environment, but do not leave only VMs. The environment must run on x86 hardware, with as few extensions as possible. (x86 is the most common hardware for developers.)
5. Document this FOSS environment. Videos, books, etc. (No, they may not be able to just look it up on YouTube in 20 years.) Licensing may be an issue.
Do not feed the trolls. Unless you're a goat. Are you a goat?
Use the shell. You can even encapsulate it in the device.
My ism, it's full of beliefs.
Some people will not get the joke and think that was a serious suggestion.
The code I work with dates back to mid 1980. That is around 30 years. Some parts are a bit hard to read, cause they coded things differently back then.
But in the whole of it, the source survived the development environment did not. The code apparently started out being coded for DOS, then ported to Unix with a number of smaller ports inbetween. Bottom line: The code is still readable, with or without the original development environment.
Not that I am recommending it but the Europeans under the Polarsys project are trying to solve the long term support problem for large projects. Ericsson with their communictation system and Airbus with their aircraft have found that they need active support for at least 20 where new features are added to systems. Then system maintenance is needed for another 15 years. I have worked on a number of Ericsson projects that have a developement system based on Solaris using IBM tools that are no longer maintained. Development is still going on and will continue for another 5 to 10 years. Ericsson and Airbus have now embraced an open source model for tools so that if the original vendor stops support, they could develop or contract out for support.
A lot of people said about using VMWARE. I wouldn't advise on that. Either go to an open-source virtual machine or, even better, an emulator. Who knows where VMware will be around 2040?
Ide: don't bother. They will be long gone by then. Keep it simple. A text editor should suffice.
Keep everything close to standard. Doesn't matter which one. C89, C++11, Python 3. Whatever. As long as you can have the source of that thing.
You mentioned ubuntu. Fine. You can still find Linux 1.0 at Kernel.org, so you can be sure that the base components of your OS will be usable for a while, and upgradable. (kernel, libc, gnu toolchain).
About hardware: either you go X86 or you go ARM (for easy availability) or you go to something specialized: IBM, or even PDP. Those things will be kept forever.
Nothing stops you from buying 500 raspberry PIs and storing them somewhere....
You are in trouble if you want a static solution. I don't know of anything that deals with the 32 bit time overflow or ask it's known as the year 2038 problem.
MPE still runs code compiled in 1972.
The fact that no one uses is is the fault of HP and the petty marketing effort they put into.
AND the competetion.
Fortunately now there is the Charon emulator from Stromasys. (But only for those who have an original hardware license.) Otherwise you get a hobby license.
Another great HP marketing (and legal) move.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
We already have a working example. It's the same Development Environment I've been using for more than 25 years: Emacs and C. It works.
I wonder if an FPGA platform could be used. Make your own CPU and stuff.
Working with a project written in Delphi. It is not quite 25 years old, but getting up there. One difference might be that we continuously maintain and improve it, it was not created once and then thrown in the corner expecting it to work forever. Although, it probably would thanks to Windows backwards compatibility. My concern would be finding the exact same hardware 10, 15, or 20 years from now. As OP mentioned, there are emulators for software and with a Linux based system you should be able to find some x86 hardware even 50 years from now that still works. The difference between that hardware and the hardware the embedded code runs on is that there is a magnitude more of x86 (compatible) hardware around compared to the embedded platform. I think you are asking the wrong question. Do not ask if there is a development environment that runs 25 years from now. Ask why the embedded platform is expected to work fine without changes for 25 years. If it does, great! But don't count on it!
We have been maintaining Stratus VOS since 1980, but it hasn't stayed static and it's very much larger than it was in 1980.
Which gets me to my real point. If you aren't going to maintain it, keep the binaries. If you are going to maintain it, it won't be in a vacuum; so, you will need to move the software into new environments.
An engineer who ran for Congress. http://herbrobinson.us