How do you preserve the IDE/toolchain over many years?

[RoGeorge]

The problem is that after a few years the toolchain used to develop the old project won't even open on the new PC.
How do you modify/recompile a project after many years?

• A laptop for each project? 
  Don't laugh, there was a dude working for the national power grid, and he had a double door heavy metal locker full of shelves, and all shelves were full of laptop bags, all nicely labeled. One laptop and its cables for each industrial equipment used in their installations. Those laptops were never updated, upgraded or connected online. TBH at first we all thought the dude was crazy, but it's the best and safest method I've seen so far, since industrial equipment tend to have a lifetime of many decades.
• Virtual machines?
• Docker?
• Something else?

[cdev]

This issue is an important one.

In theory virtual machines should all be able to present some standardized hardware profile somehow, having a standardized VM container HW platform would likely work for 9 out of 10 situations.

But the one laptop per project idea is a good one.

[coppice]

I don't think there is a single solution that will work for every circumstance. As well as the software tools, you need to keep the hardware tools, like JTAG interfaces, in a usable state. Most of that hardware is supplied without documentation to assist with repair, and without any commitment from the supplier to long term support. "Buy a new computer, and load the old stuff on it" doesn't work a lot of the time. The old code probably doesn't have drivers for the new hardware, and newer operating systems won't accept the old drivers for your hardware tools. It looks like Intel will soon remove real mode support from its CPUs, meaning lots of old stuff won't run. Virtual machines typically won't support the hardware tools you need. Its really a PITA trying to come up with a robust long term strategy that changing equipment won't derail.

Hanging on to one of the machines used for the original development work is a great strategy for the medium term, but when that dies of old age life gets hard.

[tggzzz]

Given that you probably need to survive:

• toolchain changes (e.g. compiler/IDE)
• your application's library changes (e.g. lib*.so)
• operating system changes (e.g. wayland/unity/XP/Win8)
• peripheral changes (e.g. floppys or parallel ports)
• generic hardware changes (e.g. PATA/SATA/intel/amd)
• specific hardware failures (e.g. PSU caps)

then a VM seems the least troublesome. But you need to assess the specific risks and have specific mitigations.

[nctnico]

This issue is an important one.

In theory virtual machines should all be able to present some standardized hardware profile somehow, having a standardized VM container HW platform would likely work for 9 out of 10 situations.

But the one laptop per project idea is a good one.

I disagree. Relying on old hardware means you'll find out it is broken when it is too late. IMHO a virtual machine is a good option but whatever method you choose you'll still need to test whether it works or not regulary. Especially if you are under a maintenance contract.

The specific programming hardware tggzzz mentions is a good one. If you need special dongles to program firmware then you are in even more danger. In my designs I always use microcontrollers which can be programmed using nothing more than a serial port. Even if serial ports go obsolete there will be tons of hardware out there which can do the job.

[Bruce Abbott]

The problem is that after a few years the toolchain used to develop the old project won't even open on the new PC.
How do you modify/recompile a project after many years?

You redesign the project to use available software and hardware. You do this because:-

1. You can tell your customers they have to 'upgrade' because their stuff is outdated and can no longer be supported. This keeps you in business.

2. Our economy would collapse if people didn't keep buying new stuff.

3. Others may want/need to reproduce your project, and they can't do that if it uses stuff they can't get.

[NorthGuy]

You're likely to encounter problems with IDE, but if you have command-line compilers/tools, you most likely still can run them from the command line on modern PC. So, I don't think there's anything special you need to do. Just strip the tools from their installers, move them to a fresh PC, make sure they can run and you're set.

Of course there's some obsolescence, such as all 16-bit binaries won't run on 64-bit Windows, but you always can come up with something (such virtual PC) to run them if you badly want to do it.

[tggzzz]

You're likely to encounter problems with IDE, but if you have command-line compilers/tools, you most likely still can run them from the command line on modern PC. So, I don't think there's anything special you need to do.

Some but not all C/C++ compilers change the code they generate with monotonous regularity; different optimisations become available, standard (and interpretation thereof) change, etc.

So you may be able to run compilers from the command line, but the code's behaviour may change. You can probably notice that in the middle of a project, but if there are a few years worth of compiler changes it may be more of a problem.

[NorthGuy]

So you may be able to run compilers from the command line, but the code's behaviour may change. You can probably notice that in the middle of a project, but if there are a few years worth of compiler changes it may be more of a problem.

No. If you don't constantly upgrade to newest versions, but keep using the same version of the compiler, then nothing will change.

[tggzzz]

So you may be able to run compilers from the command line, but the code's behaviour may change. You can probably notice that in the middle of a project, but if there are a few years worth of compiler changes it may be more of a problem.

No. If you don't constantly upgrade to newest versions, but keep using the same version of the compiler, then nothing will change.

True, but in practice that can be difficult to achieve, particularly if you have multiple projects with differing requirements. I've see a company really get its knickers in a twist like that.

And, of course, it is all the other components in the environment.

Keeping each project in its own VM has a certainty and simplicity.

[legacy]

A laptop per project for Windows; each laptop is also loaded with different rootfs for linux
and I also have to support an old RISC workstation with different rootfs, thus ...
... I had to buy a couple of workstations in order to be ready in case of failure

[NorthGuy]

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

Although I don't use it, I still can run command line version of Microsoft VC++ 3.1 which I bought ca 1995.

Less parts means more reliability.

[legacy]

p.s.
Keil MDK v5.18 vs keil MDK v5.20 the difference is NOT only the OS!
v5.18 runs on WindowsXP/32bit, starting from v5.20 you need Windows 64bit, i.e. Vista, Eight, Ten
but, under the professional version of MDK, trying to migrate projects is not so easy as it should be!

and there are also problems between v3.20 and v5.18 

The solution? Three different toolchains, installed in three different laptops;
this way no one is tempted to "import" a project to a different version of the toolchain.

Funny, ain't it? 

[legacy]

Keeping each project in its own VM has a certainty and simplicity.

This is the solution offered by WindRiver for the development of products based on VxWorks!
We got four pendrives of 32GByte each, and inside of each stick there was a (Oracle VirtualBox) VM.

Nice, simple, and useful! Everything was already configured and ready out of the box!
The backup was also simple and fast! (we cloned each pendrive for backup purposes)

[digsys]

The <=10 yrs plan may be fine for some, but I have huge amounts of hardware out there going 20+ yrs and even 30+ yrs
Very occasionally, I have to do updates ... it's not finding the hardware that's the problem, it's remembering HOW the FOOK I wrote the code !! :-)
I've had to resort to gumtree (ebay) on more than 1 occasion to find "old" laptops / hardware etc

[Kjelt]

VM indeed a good choice however more and more software these days needs a working online subscription.
Those will not be around or supported anymore ten years from now 

[tggzzz]

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

Although I don't use it, I still can run command line version of Microsoft VC++ 3.1 which I bought ca 1995.

Less parts means more reliability.

Microsoft has a history of that kind of thing. Remember Microsoft PlaysForSure (TM) music? Once they turned off their servers you could only continue to play it on the same processor+disc.

That and preventing me from reinstalling WinXP onto a replacement disc, and preventing me from buying Win7 to replace WinXP means that I doubt I will ever buy another MS operating system.

Arguably, in this context a VM is the single part, so that ought to be optimum w.r.t. "Less parts means more reliability".

But yes, the VM route is a risk - but is it more or less of a risk given all the failure use cases?

[tggzzz]

VM indeed a good choice however more and more software these days needs a working online subscription.
Those will not be around or supported anymore ten years from now 

Indeed.

Anyone remember Microsoft PlaysForSure (TM)? A singularly inapt name.

[digsys]

Anyone remember these days ? www.pbase.com/digsys/image/166678651/large    4pix
We had to buy an emulation kit for every processor - cost from $8,000 - $12,000 a kit. I had one for the TMS34010 graphics processor ..
THAT baby cost ~$18,000 !!! 30 yrs ago
Then some doofus decides to include all the debug hardware in the CPU / MPU itself !!! :-)  ahh memories
btw: anyone want these? FOC ... time to let history pass.

[cdev]

This is why the guy's strategy of keeping hardware capable of running all mission critical software in a working state makes sense.


At least until they make old books and computing hardware illegal.

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

Although I don't use it, I still can run command line version of Microsoft VC++ 3.1 which I bought ca 1995.

Less parts means more reliability.

[westfw]

Ideally, you keep your important products up-to-date with the latest tools.  My long-term "product" commitment at this point (in my post-retirement bliss) is maintaining the Arduino Optiboot Bootloader, and a substantial number of the patches I've applied in the last 7 years are of the "make sure this compiles (and fits) using the new x.x version of the compiler."

Keeping a set of mothballed laptops isn't an awful idea, assuming that they really include everything that you need.  Certainly for a major product, you can afford to spend $1000 ...)  (Or, you can do this as part of the normal age-out process for your computing gear.  Every time you buy a "new" laptop, you put all your "current" products on the old laptop and mothball it.)  (Alas, this ought to include external tools like programmers, as well.)  I have ... a bunch of ATtiny11s that are not supported by most current device programmers.  I have a programmer for them, but the host software relies on a PC bit-banging a "real" serial port.  And all sorts of device programmers that connect to parallel ports...)

VMs... I guess are nice, as long as you make sure that THEY keep running (which seems more difficult than keeping the product working, in some sense.)  I have ... PPC Mac Apps (and documents for them) that ran great on my G4, and then ran for years under PPC emulation on a x86 Mac.  And then x86 Macs stopped emulating PPC.  And there's that "parallel port device hardware" problem...  Could I have found a PPC VM when the x86s came out?  Probably.   When the x86s stopped supporting PPC apps? Maybe.   Now?  I dunno - I could be looking at VMing an older x86 MacOS that does support PPC...

The problem gets "different" in larger companies.   I'm sure it was someone's responsibility to make sure that entire build environments for all active branches continued to work, as the company transitioned from 680x0/HPUX build systems to Sparc/SunOS build systems to Sparc/Solaris to x86/Solaris to x86 Linux server farms, but I'm glad it wasn't mine!

[hendorog]

One approach is to check all of the (software) tools and libraries into version control along with the source code. The build process is fully automatic and grabs the code from version control, builds it and creates a deployable artifact.

Done right that allows full traceability, you can verify the configuration of the environment used to build something, and go back to a point in time and build the deployable artifact exactly as it was. 

Infrastructure as code takes it one step further and you to do the same thing with the OS and any platform level tools like an app server etc.  The binary blobs sit somewhere and a build script verifies them and then grabs the appropriate versions to build the server all automatically. The build script is checked into version control along with the code.

This was done for server based software, not EE/industrial stuff, but the principles are the same.

[nctnico]

Ideally, you keep your important products up-to-date with the latest tools.  My long-term "product" commitment at this point (in my post-retirement bliss) is maintaining the Arduino Optiboot Bootloader, and a substantial number of the patches I've applied in the last 7 years are of the "make sure this compiles (and fits) using the new x.x version of the compiler."

The problem with that is that you need to do a full test on each binary. On a complex product this can take at least a day and probably more due to stress tests which need to be done.

[technix]

Actually I don’t. I used to develop iOS apps, and Apple mandate the use of their latest tools to submit the apps (and that is why I am not moving fully to Swift on that front yet - still a moving target.) So I am used to the “minimum invariant and source dependencies” style.

The minimum invariant part must be truly invariant as way too many projects already depend on it. GNU C (the C language dialect as implemented by both GCC and LLVM/clang, not GCC the compiler itself) is an example as it is a hard dependency of Linux kernel and almost everything running on it. As is IEEE 1149 JTAG port for debug access.

Keeping the dependencies as source code means that compiler updates, as long as it don’t break the language itself (GNU C almost never breaks, Swift breaks frequently) I am not losing my dependencies.

[dgtl]

I'm doing mainly microcontroller and embedded linux development, on linux host machine. In both cases, the whole build is frozen to specific version of toolchain and libraries. All of the toolchains are installed to /opt and binaries symlinked to /usr/local/bin/arm-none-eabi__VERSION_HERE__-gcc etc. The build system of the project uses "CROSS=arm-none-eabi__VERSION_HERE__-" and this locks it to a specific compiler. For embedded linux, we use build everything from scratch principle - every release build is built fully from sources; the only pre-built piece is the bootloader blob, that does not change often. The build system references exact versions of source tarballs and a rebuild uses always same sources. The IDE is non-issue here, as it is just an editor; everything is built using Makefiles, no automatic generation used.
This works reasonably well. In the long run, things still break. For example, some pre-processing scrips of linux kernel build system do not work anymore on new machines due to some changes in perl language. We have a set of patches, that fix these kinds of behaviour where it is needed to rebuild old software.
The versions of all packages and toolchain are updated in major updates. Usually this takes quite a lot of manual work due to things breaking because of API changes etc.

[fourtytwo42]

Something I have not seen mentioned and has caught me on more than one occasion is programming hardware and it's compatibility with different pc's although I must confess this tended to be more common in the days of parallel printer ports it can and still does happen with USB ports particularly those weak on the 5V voltage.  So if your not going to keep the actual PC used for the project it may well be a good idea to go through the motions of programming with the new PC before binning the old one.

[coppice]

Something I have not seen mentioned and has caught me on more than one occasion is programming hardware and it's compatibility with different pc's although I must confess this tended to be more common in the days of parallel printer ports it can and still does happen with USB ports particularly those weak on the 5V voltage.  So if your not going to keep the actual PC used for the project it may well be a good idea to go through the motions of programming with the new PC before binning the old one.

The problem was mostly parallel ports in the last 5 years or so of them being a normal feature of PCs, and mostly in notebooks. A lot of development tools were made very quirky by the reduction in pin drive strength during that period. It was the final driver for many vendors to get their USB tools out the door, although the lack of parallel ports on notebooks would soon have created another impetus.

I wonder if there is a lesson here which will be repeated? The use of USB for most current tools means you no longer have the issue of using an interface for a non-intended purpose, and having to live with any quirks the evolution of the port hardware creates for you. Many high consumption USB devices, like hard disks, have required power from multiple USB sockets, which might leads to quirks as the USB ports evolve. However, the high consumption development tools I have seen use a power brick to get their power. So, they do not use USB in any kind of non-standard manner. As long as there are USB ports, the hardware of the tools should be OK. The software drivers, on the other hand.......

[tszaboo]

The most scary thing for me is embedded linux development. Our current procedure for setting up a new dev enviroment requires to pull data from a dozen online repositories. And the entire thing is a big blob of a black box, nobody really understanding what the actual hell going on inside.

If there is a single failure, like a server goes down, or files get deleted, or anything like that... well good luck finding out how to do it. Or what is actually missing. How on earth can anyone recommend embedded linux for anything is beyond me.

And then, you consider connecting your linux to the internet. Well good luck. Constant updates to every stupid thing, kernels coming faster than fully testing the functionality.

So we have a VM, and if that doesnt work, hope that nothing changed on the internet.

"I like to find out why someone else's code doesnt compile properly." -said nobody ever.

[coppice]

The most scary thing for me is embedded linux development. Our current procedure for setting up a new dev enviroment requires to pull data from a dozen online repositories. And the entire thing is a big blob of a black box, nobody really understanding what the actual hell going on inside.

If there is a single failure, like a server goes down, or files get deleted, or anything like that... well good luck finding out how to do it. Or what is actually missing. How on earth can anyone recommend embedded linux for anything is beyond me.

And then, you consider connecting your linux to the internet. Well good luck. Constant updates to every stupid thing, kernels coming faster than fully testing the functionality.

So we have a VM, and if that doesnt work, hope that nothing changed on the internet.

"I like to find out why someone else's code doesnt compile properly." -said nobody ever.

How is that worse than using any other platform?

[legacy]

Keeping a set of mothballed laptops isn't an awful idea, assuming that they really include everything that you need

for me it works great!
There is also tons of hw equipment which needs the LPT port, the PCMCIA port, etc
all tasks where a virtual machine sucks great, and I can't loose the working days to fix them.

The problem gets "different" in larger companies.   I'm sure it was someone's responsibility to make sure that entire build environments for all active branches continued to work, as the company transitioned from 680x0/HPUX build systems to Sparc/SunOS build systems to Sparc/Solaris to x86/Solaris to x86 Linux server farms, but I'm glad it wasn't mine!

That's (a part of) my duty. A freak Hell 

[legacy]

All of the toolchains are installed to /opt and binaries symlinked to /usr/local/bin/arm-none-eabi__VERSION_HERE__-gcc

We need to support gcc-v2.95, do you really believe it's a piece of cake?
gcc-v2.95 is broken on modern rootfs due to glibc incompatibility!

Thus, what you MUST do is having tons of minirootfs, to chroot into! Each one with its libraries, and tools and dependencies.

Old tools (even Makefile) has changed during these years, even the motorola assembly GAS for m68k: completely incompatible with legacy projects!

Do you want? Can you spend weeks of time to import legacy projects into modern toolchains? It depends IF the customers agree and IF they pay for it.

Usually no!

Oh, and beyond the rootfs we also have kernel incompatibilities! Thus what you MUST do is putting everything into a VM.


Your solution only works for a short window of time, say no more than five-six years 

[legacy]

Another thing we do is: cloning the whole hard drive partition into a chunk of external memory, usually stored into a server's array of disks. We usually choose 32GB for the root (linux or windows), thus it comfortably suits the size of 40GB offered by DLT-tapes (as backup).

We also have a special partition in the laptop for the bootstrapper. It's a linux partition, embedded profiled (forget the graphical GUI), which contains tools like "ssh", "scp", "dd", and tons of scripts usable to restore the OS-partition through the net.

"Draft-projects" are always stored in the second partition (VFAT), this they are never affected by any restore/clone procedure, while "in-trunk-projects" are stored into a server, and can be cloned back on demand.

These tricks have saved us from the need of buying a laptop for each project since we can group similar projects to the same laptop, where people can clone the required software into the harddrive.

[Howardlong]

The biggest risks nowadays comprise not just software, but parts too. My risk list is:

o Company instability, including mergers/acquisitions, bankruptcy or illiquidity.

o EOL'd parts

o Subscription- or time-limited software with either phone home or date/time lookup - AVOID if at all possible!

o Deprecated features, and quicksand software (frequent development-driven agile half-finished releases with shoddy QA [there is a definite correlation!])

I've been directly affected by all of these. At my worst point, I found myself having to completely redesign a product after a fabless supplier went bust, frustratingly with 1/4 million devices idly sitting at their fab assembler, but inaccessible due to the liquidator not releasing them. A year later I had a call asking me if I wanted any, but I'd already redesigned the product. Liquidators are stupid sometimes, I'd originally offered them £70k for the lot, they turned me down, and wouldn't release any at all: a year later they were worth bugger all, as all their customers, like me, had moved on.

EOL'd parts happen for me on pretty much a monthly basis, it's part of life. Often they're just jelly bean passives but for some parts you have to do a substantial re-characterisation. There's not a lot of practical difference between EOL or an out of stock item, you still have to re-test. For some parts there is an MOQ, which ties up capital for an extended period depending on your run rate, and that in itself has risk. While it's a reasonable practice to select more generic parts, it's not always practical, it's the usual set of balancing engineering requirements and priorities, and compromising appropriately.

Maintaining software builds are frustrating, particularly in mothball scenarios, and my solution is a frozen VMWare VM, but even that is not fool proof if you have phone home or subscription time limited dependencies. Even fiddling dates/times nowadays has its risks as it breaks things like Kerberos and certificates.

Deprecated software or quicksand software can be mitigated against with VMs, but there is a remaining problem in that you need to maintain currency on older technology, and its quirks. Personally I prefer that, to having to continually maintain dozens and dozens of mothballed environments.

The benefits of a VM over physical hardware for build environments is that the HALs are consistent, you can archive them more easily, and you can move them around. you can also fiddle dates and times, but this is becoming less easy to do. The downside is that if you have some older stuff that has dependencies on physical COM or LPT ports, and they're targeted directly, you're often out of luck.

[NorthGuy]

Arguably, in this context a VM is the single part, so that ought to be optimum w.r.t. "Less parts means more reliability".

"Too big to fail" some would say.

[Tomorokoshi]

I have a project where the code base goes back to 2003. Latest build was this summer. CCS compiler with old Microchip IDE. Easily copied to another computer if needed.

Another project is 10 years old, but it uses an IDE and a compiler that have a network license. This is something I like to avoid, but:

((micromanagement - management) + engineering) = microengineering

drove that decision, making eventual updates tenuously dependent on the availability of the network, the skills of the maintenance of the systems, etc.

Make full backup copies of source code in the clear. Include all development tools, including the source code and build tools of any conversion programs that are used. Also backup the programs that run the programmer. Don't rely on access to the repository. Those also can get lost, upgraded out of existence, or broken as systems move on.

For an embedded systems include a directory with datasheets of all the parts.

Finally, make a long, detailed document that covers every step of the build process, from installing the development tools to doing the build and programming the target. Include basic guidance of the source structure and key areas and functions. Perhaps write it in Word, use a lot of screenshots, and save to PDF.

[nctnico]

The most scary thing for me is embedded linux development. Our current procedure for setting up a new dev enviroment requires to pull data from a dozen online repositories. And the entire thing is a big blob of a black box, nobody really understanding what the actual hell going on inside.

Perhaps someone should think about that and -like me- keep all the downloaded source files together with the environment. Actually embedded Linux environments are pretty much self containing eco systems. Everything -including the compiler- is build from scratch. The biggest problem is that script languages like Python, Yacc, Bison, etc have incompatibilities between versions so it is best to have a virtual machine to also keep the OS environment stable.

Knowing how the build environment works is a matter of spending time on it. It isn't black magic.

[technix]

The most scary thing for me is embedded linux development. Our current procedure for setting up a new dev enviroment requires to pull data from a dozen online repositories. And the entire thing is a big blob of a black box, nobody really understanding what the actual hell going on inside.

If there is a single failure, like a server goes down, or files get deleted, or anything like that... well good luck finding out how to do it. Or what is actually missing. How on earth can anyone recommend embedded linux for anything is beyond me.

And then, you consider connecting your linux to the internet. Well good luck. Constant updates to every stupid thing, kernels coming faster than fully testing the functionality.

So we have a VM, and if that doesnt work, hope that nothing changed on the internet.

"I like to find out why someone else's code doesnt compile properly." -said nobody ever.

For embedded Linux just maintain only the parts of code you actually touched, and leave everything else to some community. If, for example, Debian works on your board and is not creating too much of a fuss, just go with Debian with your board’s specific kernel. All major package managers, be it Fedora’s yum or Debian’s apt, can be set up to pull updates automatically. Whenever there is an upstream change you just start by validating the binary package, which should be a quick pass in the CI against existing binaries.

Actually The two best existing distributions to base your own embedded systems in would be Debian and CentOS. Both distributions are known for their stability: Debian requires packages to be bug free for a few years before entering stable, and CentOS pull all source code from the commercial Red Hat Enterprise Linux. Those are both very much preferred in data centers for mission critical systems, and their respective maintainers try their best not to break things when upgrading packages.

[mac.6]

The most scary thing for me is embedded linux development. Our current procedure for setting up a new dev enviroment requires to pull data from a dozen online repositories. And the entire thing is a big blob of a black box, nobody really understanding what the actual hell going on inside.

If there is a single failure, like a server goes down, or files get deleted, or anything like that... well good luck finding out how to do it. Or what is actually missing. How on earth can anyone recommend embedded linux for anything is beyond me.

And then, you consider connecting your linux to the internet. Well good luck. Constant updates to every stupid thing, kernels coming faster than fully testing the functionality.

So we have a VM, and if that doesnt work, hope that nothing changed on the internet.

"I like to find out why someone else's code doesnt compile properly." -said nobody ever.

For embedded Linux just maintain only the parts of code you actually touched, and leave everything else to some community. If, for example, Debian works on your board and is not creating too much of a fuss, just go with Debian with your board’s specific kernel. All major package managers, be it Fedora’s yum or Debian’s apt, can be set up to pull updates automatically. Whenever there is an upstream change you just start by validating the binary package, which should be a quick pass in the CI against existing binaries.

Actually The two best existing distributions to base your own embedded systems in would be Debian and CentOS. Both distributions are known for their stability: Debian requires packages to be bug free for a few years before entering stable, and CentOS pull all source code from the commercial Red Hat Enterprise Linux. Those are both very much preferred in data centers for mission critical systems, and their respective maintainers try their best not to break things when upgrading packages.

And then you still have heartbleed-class issues.

There is no free lunch, supporting software for xx years cost yy in time and money. You can mitigate it (VM/redundant hw...) but not eliminate it.
And be sure to sanity test your environment often (jenkins & al) to be sure to catch failure as soon as they happen, not when urgent work is needed.

[Mr. Scram]

Sticking toolchains on laptops is a terrible idea. Hard drive bearings become stuck. SSDs are probably a bit more resilient, but aren't guaranteerd to work after long periods of time either.

You need to be as independent of hardware as you can be and especially specific hardware.

[technix]

And then you still have heartbleed-class issues.

That is why for Internet-connected devices you need a mechanism to push updates to the devices. And firewall things as much as possible.

There is no free lunch, supporting software for xx years cost yy in time and money. You can mitigate it (VM/redundant hw...) but not eliminate it.
And be sure to sanity test your environment often (jenkins & al) to be sure to catch failure as soon as they happen, not when urgent work is needed.

Using the FOSS community can be considered a way to outsource that burden. It wouldn't be surprising for me to see someone building a piece of custom hardware using other brand's silicon, yet still runs Raspbian as the user land environment. For that development team they effectively outsourced the maintenance of their base environment to the Raspberry Pi Foundation.

[coppice]

Sticking toolchains on laptops is a terrible idea. Hard drive bearings become stuck. SSDs are probably a bit more resilient, but aren't guaranteerd to work after long periods of time either.

You need to be as independent of hardware as you can be and especially specific hardware.

SSDs need to be powered up regularly to refresh themselves. A hard disk drive, properly stored, doesn't usually get stuck bearing. The nasty sticking issue with hard disks is the head sticking to the disks, and tearing themselves apart on restart.

[Mr. Scram]

SSDs need to be powered up regularly to refresh themselves. A hard disk drive, properly stored, doesn't usually get stuck bearing. The nasty sticking issue with hard disks is the head sticking to the disks, and tearing themselves apart on restart.

That SSD story mainly concerns older drives near the end of their lives. The author has stated how he regrets the actual context of the story generally is lost. Losing data through that failure mode at least is very unlikely if the disk is relatively fresh.

Stuck bearings is a real problem for drives stored for longer periods of time. It won't happen regularly after 2 years, but the whole point of the laptop idea is to have a surefire tool chain even after a decade.

https://www.pcworld.com/article/2925173/debunked-your-ssd-wont-lose-data-if-left-unplugged-after-all.html

[legacy]

A hard disk drive, properly stored, doesn't usually get stuck bearing. The nasty sticking issue with hard disks is the head sticking to the disks, and tearing themselves apart on restart.

I have harddrives bought in 1995. Still working!
Anyway, cloning the harddrive into a remote server (and into a backup media, i.e. tape and MO) is mandatory for us.

[Mr. Scram]

I have harddrives bought in 1995. Still working!
Anyway, cloning the harddrive into a remote server (and into a backup media, i.e. tape and MO) is mandatory for us.

How many hard drives bought in 1995 are currently still working?

[technix]

AFAIK the only really permanent data storage medium is actually mechanically pressed optical discs. That is, CD-ROM, DVD-ROM and BD-ROM inside their jewel cases, not the recordable or rewritable ones.

[Mr. Scram]

AFAIK the only really permanent data storage medium is actually mechanically pressed optical discs. That is, CD-ROM, DVD-ROM and BD-ROM inside their jewel cases, not the recordable or rewritable ones.

Pressed discs rot too.

[technix]

AFAIK the only really permanent data storage medium is actually mechanically pressed optical discs. That is, CD-ROM, DVD-ROM and BD-ROM inside their jewel cases, not the recordable or rewritable ones.

Pressed discs rot too.

Depending on material. There are archival optical discs made out of strengthened glass that does not rot. Also the metal or glass mold (master) used to press the disks does not rot easily too, which can be preserved to press more discs upon request.

[legacy]

How many hard drives bought in 1995 are currently still working?

From our Olivetti Philos 486DX2 DOS laptops? They are all work
I can take a pic. They are 80MB, 120M, 340MB, made by Seagate.

[legacy]

One of the most used DOS toolchains is Called "EVO" and is targeted for DSP56002 by Motorola.
It comes with a special PCMCIA type1 card, and it also requires the LPT port and the COM port.
But, I am willing to migrate the whole to a Pentium3 laptop, IBM T23.

[coppice]

AFAIK the only really permanent data storage medium is actually mechanically pressed optical discs. That is, CD-ROM, DVD-ROM and BD-ROM inside their jewel cases, not the recordable or rewritable ones.

CD-ROMs are hopeless for long term storage. The lacquer over the metalisation is porous. If you live in a place with high humidity, like HK or Singapore, pressed CDs fail at quite a high rate. Pressed DVDs and BDs are supposed to overcome this, as they use a more substantial covering for the metalisation. I don't know how big an improvement they offer, but my experience suggests they are genuinely better.

[Towger]

I have huge zipped files with VB3 and various associated libraries/3rd party DLLs.  Newer stuff is in VMs, I even got a Windows 2 VM working a few years ago.

Something which has been on my mind for years now is how resistant various media is to a magnetic pulse.  Every now again I backup the bare essentials to DVD, just to be sure and in recent years the cloud.  Of course basic survival after such an event may take precedence.

[technix]

I have heard of supposed archival-grade SD and microSD cards out there that uses SLC cells for lower refresh requirement and less likelihood to fail, and a controller that can do periodical refresh on its own. Maybe those can be useful?

[Jeroen3]

Heh, just try getting IDE's online when the cloud login or license server of decades ago is unavailable.

[tggzzz]

Heh, just try getting IDE's online when the cloud login or license server of decades ago is unavailable.

Just so.

That's the reason I don't use anything like that for anything that would take me more than 1 week to recreate from scratch.

[brucehoult]

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

There are open source community-maintained virtual machines now, which can use your old VM images: VirtualBox if you want to run one x86 OS (version) on another at essentially full performance, or qemu to run anything on anything at typically 5 times performance slowdown -- or faster than before if you have the latest shiny i7 box and you're emulating something 15 years old.

[Karel]

Heh, just try getting IDE's online when the cloud login or license server of decades ago is unavailable.

Apart from the download of the software itself and maybe the purchase of a license key, which can be stored in a safe place,
if you can not install it and use it without an internet connection, then don't use it at all.

[technix]

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

There are open source community-maintained virtual machines now, which can use your old VM images: VirtualBox if you want to run one x86 OS (version) on another at essentially full performance, or qemu to run anything on anything at typically 5 times performance slowdown -- or faster than before if you have the latest shiny i7 box and you're emulating something 15 years old.

You can make qemu faster if you run Linux as the host OS, go through the process of getting KVM up, and the guest system have the same or a subset of the host instruction set.

For example, it is actually possible to debug Cortex-M4F code at near full speed on Raspberry Pi using KVM and run the M4F code on the Cortex-A7 core, by using Linux app debugging facility and KVM.

[Kjelt]

if you can not install it and use it without an internet connection, then don't use it at all.

As long as we have a choice that is good advice but the trends are against us 

[Howardlong]

Heh, just try getting IDE's online when the cloud login or license server of decades ago is unavailable.

Apart from the download of the software itself and maybe the purchase of a license key, which can be stored in a safe place,
if you can not install it and use it without an internet connection, then don't use it at all.

I agree, I've just been caught by exactly this. I bought recurring annual licences for some development software I started using about six years ago, at around £500pa. I remember finding out that it phoned home about once a week when I tried to use it on a long haul flight on my way to a customer to demo something with it. Needless to say it refused to work with no internet connection. I was not best pleased, but unfortunately I'd already invested a lot of time in the product so wasn't about to switch to an alternative.

Fast forward to now, I try to do some maintenance, and I discover that that the company has withdrawn their product and the licence servers are now switched off.

I can just about deal with products that need to phone home on a one-off basis during installation, and even those that have an optional recurring maintenance component, but anything that is controlled externally, needs to phone home frequently, and might break at the whim of unforeseen external circumstances I'm afraid is too much of a risk to even contemplate now.

[brucehoult]

if you can not install it and use it without an internet connection, then don't use it at all.

As long as we have a choice that is good advice but the trends are against us 

I disagree.

More and more vendors are realising that the money is in selling hardware not selling tools, and that in-house efforts aren't going to match the quality of gcc or llvm anyway, so it's easier to leverage off them and even upstream support for proprietary CPUs into the main repository. And the same for other tools such as IDEs, debuggers, programmers.

We are now even starting to see open source tools for programming FPGAs.

[nctnico]

Heh, just try getting IDE's online when the cloud login or license server of decades ago is unavailable.

Apart from the download of the software itself and maybe the purchase of a license key, which can be stored in a safe place,
if you can not install it and use it without an internet connection, then don't use it at all.

I go one step further: I don't buy software for which there isn't a hack available which disables tying the software to a particular machine or piece of hardware. After all it is very likely that a company can't create the license keys needed to install it on a different PC for a very old product even if they wanted to.

BWT this thread suddenly reminds me of this. One of my customers creates electronic art and they also some have pieces in a museum. Now the curator of that museum wanted all the sourcecode and schematics to be able to have information on how the artwork works so they can preserve it (keep it going or replace the hardware/software) for generations to come.

[bgm]

The problem is that after a few years the toolchain used to develop the old project won't even open on the new PC.
How do you modify/recompile a project after many years?

• A laptop for each project? 
  Don't laugh, there was a dude working for the national power grid, and he had a double door heavy metal locker full of shelves, and all shelves were full of laptop bags, all nicely labeled. One laptop and its cables for each industrial equipment used in their installations. Those laptops were never updated, upgraded or connected online. TBH at first we all thought the dude was crazy, but it's the best and safest method I've seen so far, since industrial equipment tend to have a lifetime of many decades.
• Virtual machines?
• Docker?
• Something else?

Ooohhhh a subject near and dear to my heart because I have been *burnt* by this *SOOOO* many times .... 

I have been tossing the around the idea of writing an article on this because this is a real ugly problem and one that I personally deal with far too regularly.  I haven't done so to date because it personally gets me so angry and irate and every time I start .. I start frothing at the mouth as it is something that I personally can do very little to change. 

That said ... lets see if I can answer in some way the crux the problem. 

There are a number of separate, but very related problems with this. 

>Physical hardware Devices
>Logical Software

Physical hardware Devices

For physical hardware devices where you need a physical hardware ... that is a bit of a challenge.  I've seen sites which use laptops kept in storage for this purpose.  I've also seen what happens when said laptops get dragged out after 10 years of non-use only to find that they no longer power up. 

For this one ... I don't have a good answer.  Biggest issue I've had to deal with to date is software which has physical security keys that require parallel port dongles.  These are a right and royal pain in the arse and a USB-Parallel converter usually doesn't cut it (unfortunately). 

If a device is to be put into storage like this, make sure it is imaged before you do so, the image is checksummed and that you periodically power the device up so that you can be assured that it is still good.  The last thing you need is to have to go racing for the laptop at a critical point only find that it doesn't work ....

This begins what we in the industry like to say is the:
Beginnings of a bad day (Tm) ....

Logical Software

Software has it's own subset of problems ...

#1.  Software OS support.  If the software you use will only run on Windows 95, Windows NT/2000/2003/XP and so on then keeping a VM of the supported OS is insanely helpful.  I deal with this with a device programmer that I have which has drivers that will *ONLY* work on XP.  Windows 7, 8 and so on simply won't allow it to work.  My options ... zip, zilch .. nada... so I'm stuck with a device programmer that can *ONLY* work with XP (vendor has long ceased to exist). 

For this particular problem, VMs are a godsend.  Whether you are using VMware (workstation, fusions, etc), Parallels, DOSBOX, etc ... you get the idea.  They can allow you to get around this particular sticking problem.  In my day job, I spend a large chunk of my time in a DOS VM that runs PALASM ... 'nuff said ... 

#2.  Time locked icensing.  Some software has time locked licenses.  PRIME offenders in this category are the PLD vendors (Altera, Lattice, Xilinx, etc) which insist on shipping their wares with LMgrd abomination.  This means that even if you keep a VM with the software (and a OS that is supported) in VM, the moment you power it on ... guess what ... you are *HOOPED*.  It won't run as the software is then locked.  In some cases you can sort of fool it by setting a VM date to a date in the past, but that is just plain clunky. 

An even *WORSE* situation is when you come in after the fact and you have no working image to start from.  Then you have to acquire the software and license ... and if you can't ... well ... to put it bluntly ... you're 100% screwed.  I have personally been on the sharp end of this stick with this one from products from both Lattice and Cypress.  I reserve a particular hatred of the MBAs who dreamt up such levels of barstardry ... no really I do.  If ever there was a reason to have the MBAs of the world (along with their legal advisers) lined against a wall and shot ... well .. this would be it. 

In all though, there really isn't a lot that you can do for this particular case. 

#3.  Data "locking" because of above.  In most cases, design files, etc can typically be preserved and/or exported.  When you have software that stores its data in a encrypted form that can't be exported or read because of the #2 above ... then that is when I totally loose it.  Unfortunately this is a particular level of EVIL that *DOES* happen ... 

Only option for this particular problem is that whenever you have a design that is pretty much "complete" ... it really should be "exported" into a common digital form (a PDF at the least) and where possible, at the very least an analog image (i.e. a printout) should be produced as well. 

A schematic printout is 100% better than *NOTHING* ... reverse engineering a control board after the fact because the files are locked up in a proprietary format because the original designer did it that way is no fun I can tell you. 

#4.  Cloud based barstardry.  When your software is both time locked and also cloud locked, you are even more screwed than the above.  In that case, if the vendor goes broke or they won't support your old tool, congrats ... you are 100% screwed and you are also screwing the poor barstard who has to come in afterwards to deal with the mess left behind. 

In regard this particular issue, I will say this up front and right to the point now, no matter who you are, or who you work for ... 

IF YOU USE A CLOUD BASED EDA TOOL FOR SOMETHING THAT IS TO BE SUPPORTED INTO THE FUTURE ...YOU ARE AN IDIOT!

For the above, just like in problem #3, keep a printout.  Scan it if you have to so that you have at least a digital copy as well (if you can't print and/or export to PDF or something else equally readable). 

Summary

So .. what *CAN* be done?  Well ... in truth .. for some things ... not really a lot.  Ultimately all of these companies only answer to the Almighty Dollar ...

If people were to stop *SPENDING* money on such organisations who product products that have biblically awful EDA software licensing constraints, then they would stop doing it. 

Ultimately using open source tools in the only real way that you could really assure yourself that your design will be maintainable into the future. 

The problem at this stage is that there is very few options though. 

In the SCHEMATIC and board LAYOUT space ... KiCAD and a few other open source products are fast becoming viable alternatives to the level of barstardry that the likes of Mentor, Altium and Autodesk would like to subject us to. 

In the PLD area though ... the pickings are a hell of a lot worse.  There really isn't far too many options if you want to take some Verilog and/or VHDL and synthesise that into silicon.  Most of the physical device vendors lock their products with either their own software, or software sub-licensed from others and in most part ... their software licensing is pretty bloody awful. 

I would be *WONDERFUL* if we could say take iVerilog and then have a synthesis module for it that allows us to target all of the various CPLDs and FPGAs on the market ... but ... that isn't going to happen in the near future.  Even for long since EOL products, the vendors aren't releasing the source code for their toolchains so basically when they EOL their chip ... you are still screwed to a greater to lesser degree. 

It would be wonderful if they "did" open source their toolchains for EOL products ... but ... they don't, and realistically, I can't see them changing unless they were forced to by legislation. 

It's a sad fact of life but typically most designers don't have to look after and support their creations in 10 years time, so they ultimately don't give a rats arse about what happens in regard to availability of the toolchain that they use when they create it in the beginning.  This is something that I would dearly *LOVE* to change in the industry. 


... and on that note ... I'll get off my high horse, put my claws away and try to calm down with a nice cup of tea ... 

/BGM

[digsys]

Yup, pretty much agree, with similar experiences. I did fix ONE thing many years back, after falling foul of this, back when dev tools were
astronomical ... I built every PC that I supplied / maintained to customers with EXACTLY the same hardware, plus I kept several spare parts.
So I have app 3 dozen organs that I can rely on .. that fixed the hardware / re licensing XP3, win7 needing to "talk" to base issue.
(Plus I have cracks IF I ever need them). Older Win versions aren't a problem anyway.
I also ran dummy "failed to call back to base" scenarios long ago (with software) to make sure I had an escape route. I did get caught out with
Keil / SIlabs a couple yrs ago, but thankfully, a flurry of emails and forum posts got that working again. It's NOT a nice feeling.

[Sal Ammoniac]

Keeping a set of mothballed laptops isn't an awful idea, assuming that they really include everything that you need

for me it works great!

What are you going to do if, years from now, you turn on one of those mothballed laptops and it doesn't boot?

[coppice]

Keeping a set of mothballed laptops isn't an awful idea, assuming that they really include everything that you need

for me it works great!

What are you going to do if, years from now, you turn on one of those mothballed laptops and it doesn't boot?

What do you think the ability to cry exists for?

[james_s]

I have a variety of solutions. A couple of old laptops used for specific purposes, VM's under VirtualBox that I can use on any of my PCs, and I have a hot swap SATA bay on my desktop PC with a selection of hard drives I can pop in to boot a specific OS bare metal. Of course this requires that the hardware is supported under the OS, my onboard video lacks a driver for WinXP for example.

Additionally after being burned numerous times by newer versions of software that were worse than what they replaced, I tend to maintain a "If it ain't broke, don't fix it" policy and rarely upgrade anything anymore. A couple years ago I finally replaced my nearly 10 year old desktop that still ran XP and I expect I'll run my current Win7 desktop for at least 10 more years.

[legacy]

What are you going to do if, years from now, you turn on one of those mothballed laptops and it doesn't boot?

Tell me a scientific reason to justify it!

[tggzzz]

What are you going to do if, years from now, you turn on one of those mothballed laptops and it doesn't boot?

Tell me a scientific reason to justify it!

Start with ion migration, dry electrolytics, and these pretty and scary pictures.

Alternatively, just take a cursory look at the "repair" sub forum.

[Mr. Scram]

Tell me a scientific reason to justify it!

Rotating parts that get stuck, for one.

[legacy]

Rotating parts that get stuck, for one.

rotating w_h_a_t? hinges ?
yes, hinges may failure, but it's not a critical failure

[Mr. Scram]

rotating w_h_a_t? hinges ?
yes, hinges may failure, but it's not a critical failure

Until not very long ago, most computers came with rotating media

[legacy]

Until not very long ago, most computers came with rotating media

mechanical harddrives? why should they fail?
I have TONS and TONS of HDs made in 90's, and they are perfectly working!

They are CHS instead of LBA! This may be the real problem. But it's a software problem.

[Mr. Scram]

mechanical harddrives? why should they fail?
I have TONS and TONS of HDs made in 90's, and they are perfectly working!

They are CHS instead of LBA! This may be the real problem. But it's a software problem.

Because the bearings get stuck. It's a not too uncommon failure, one which is obviously more likely in unused systems.

[coppice]

Until not very long ago, most computers came with rotating media

mechanical harddrives? why should they fail?
I have TONS and TONS of HDs made in 90's, and they are perfectly working!

They are CHS instead of LBA! This may be the real problem. But it's a software problem.

You've lived a wonderfully charmed life. Most of us aren't so lucky. Most of us have experienced large numbers of hard disks randomly dying, and losing everything they contain.

[Mr. Scram]

You've lived a wonderfully charmed life. Most of us aren't so lucky. Most of us have experienced large numbers of hard disks randomly dying, and losing everything they contain.

Hard disks typically are the most fragile part of a computer, and unfortunately the part that's hardest to replace without losing more than just the value of the part.

[legacy]

Most of us have experienced large numbers of hard disks randomly dying

Bah, what is that related to? The weather? The state or quality of being humid in rooms?
What you are talking about is, translated to my experiences, with HDs stacked in the North of Italy and in the center of Denmark, only three dead 90's HDs in a lot of 114!

That means (114-3/114) >> 90% of evidences in resulting "working" in a window of 20 years!!! Probably they won't last more, but the MBTF of modern electro-mechanical-ones says they will last more than 50 years.

and losing everything they contain.

Reason why, you should look my pic above! Different media of backup may offer different opportunities to survive to the time-wiper 

It means: we have the backup of every harddrive in every old laptop! If the HD fails, no problem, we have an equal harddrive, and we have the backup, thus it can be reloaded in 25min!

[legacy]

oh, the same applies to my X61S laptop!

It's loaded with WindowsXp and tons of programs which must be supported for a while.
We bought a stock of equal harddrives (sATA), exactly the same model installed in the laptop, and the whole 160GB harddrive has been loaded in tons of backup medias. Now, the trick here is:

WinXP was installed in a slice of 30Gbyte, so it can be saved into a CF of 32GB, or into a rav-cart of 35GB, or into a tape of 40GB, or ... in all of them 

[james_s]

I've had hard drives fail a few times, but not really all that often. I have numerous 20-30+ year old computers that still work just fine. Occasionally one of the really old hard drives will suffer "stiction" and I have to give it a twist to get the drive spinning but then it's fine. I've also had the RLL drive in my original XT lose its data but a low level format resurrected it.

[Kjelt]

The trick is to find a laptop which hardware is still supported with XP and has a serial and parallel port.
I luckily found one in a HP 85xx series workstation laptops with the cheap dockingstation providing lpt and com.
I want to buy some spares for the future but they are still pricy.

[MT]

Deep surface micro laser lithography onto granite stones!  Runestones ver2 ,would most likely last 1500 years! 
No bearings that can lock, no tinn wiskers, no ion migration, no electro pulse erase, no hardware dependencies,
no cloud storage, no licence dependencies,no Micropop or linux dependencies etc.

[westfw]

Most of us have experienced large numbers of hard disks randomly dying, and losing everything they contain.

While stored in a closet?  All backup media have failure modes, but I think a mothballed laptop has fewer than most (by all means do additional disk backups onto other media as well...)

I wonder, if you're using mothballed systems, or hard drives in general, whether it is a better strategy to power them up "periodically", or leave them untouched?

FINDING things is a problem.  In theory, every year I do a full copy of everything to a fresh and otherwise unused external hard drive, stick a date on it, and put it "offsite."   But in the event I ever actually need to recover something, figuring out which of the dozens of hard drives is likely to have the "best" copy of something is going to be a challenge.   Especially if I don't need it till several years after it's been gone.  I've had this happen a couple of times - "I'm pretty sure I have a copy of that 8085 emulator I wrote in college, because I kept copying it to each new place I worked, and each PC, and each PC got copied to each new PC, and ... now I can't find it!  It might be on the mothballed XXX system in E:/Old-Computer/Drive-D/Old-Computer.zip/Archive/Score/SRI/Wharton/8085.mac or something like that.  But it's not really worth the effort to search for."
(Easier for a commercial project where you can theoretically earmark an entire "backup" to a particular project.)

[technix]

I wonder how does a QR codes engraved on glass or stainless steel fare?

[westfw]

I wonder how does a QR codes engraved on glass or stainless steel fare?

I thought we were talking about preserving the full toolset needed to recreate a product; source code, compilers, SW tools, HW tools, computer HW to talk to the HW tools, etc.
QR codes don't even come close; we've only picked on disks because they seem to be the most fragile of the components involved.

[legacy]

LoTek steampunk

oh, yeahhhhhh, I really-really envy punched cards! They are made of paper, with holes, they can never be wrong, not even after 50 years!

Of course a mouse can give a bite and you will lose a bit of information, but not the whole! You don't need to stack them inside a lead box! Magnetic fields can't damage, vibrations can't damage. Cool winters and hot summers can't damage. They can burn in fire, and have mold, but it's not a real problem if you put them into cold rooms, and some natural caves can be used as well.

They are WORM media (write only, read many), slower than MO-WORM, just a few bit/sec during the write process instead of MByte/sec, and you need a machine bigger than Satan's fridge to sort them, and you need a tower to stack them if you divide the file's size of your backup by the size of bit you can put on a punched card: but hey? there is no rotating mechanical part, and they were solid-state media years before SSD, and, even if they were made more than fifty years ago, they are still more reliable than modern media

so, you can stick the slogan-in: Lo-Tek, the promise you will!

lo-Tek is so coooooooooool!!!! At least because it looks like a genre of science fiction that typically features steam-powered machinery rather than advanced technology 

[legacy]

oh, about that: what about FeRam harddrives?

When will we see them in the market? And how good will they look? Flash-SSDs are not so good because of rewrite-cycles, and current leakage in floattingGate-cells. They need to be refreshed cyclically by the apply of power supply, otherwise data won't be retained out of the window of 10 years 

[coppice]

oh, about that: what about FeRam harddrives?

When will we see them in the market? And how good will they look? Flash-SSDs are not so good because of rewrite-cycles, and current leakage in floattingGate-cells. They need to be refreshed cyclically by the apply of power supply, otherwise data won't be retained out of the window of 10 years 

You won't see general purpose FeRAM disk drives, unless there is some breakthrough improvement in FeRAM density. They would be far too expensive. There might be a niche market where cost is not an obstacle, because the lifetime benefits of FeRAM are so critical to the application.

[legacy]

You won't see general purpose FeRAM disk drives, unless there is some breakthrough improvement in FeRAM density. They would be far too expensive.

Yes, right! I have recently built an home-made cartridge for a total of 4MB of SMD chips. It's useful for my 68020 board, it contains programs and data, nothing serious, and I was lucky and I got some sample-chips. The density is not so good. Too many chips on the PCB to have just 4MB, that sounds like if it was a ram-disk made in 80's 

(do you remember pics published on Byte magazine? My home-made cartridge looks like those loooooooong PC-cards full of chips)

Anyway, the question is different: how better are FeRam disk drives vs Flash disk drives, in terms of reliability in a large time-windows? How long the data retention will last on there? Shorter, or longer than on flash SSDs? 

[tggzzz]

oh, yeahhhhhh, I really-really envy punched cards! They are made of paper, with holes, they can never be wrong, not even after 50 years!

Paper absorbs humidity, swells, jams in the reader and is damaged.

Plus you can drop the deck of cards.

Punched paper tape is less prone to those problems and is more compact.

[coppice]

oh, yeahhhhhh, I really-really envy punched cards! They are made of paper, with holes, they can never be wrong, not even after 50 years!

Paper absorbs humidity, swells, jams in the reader and is damaged.

Punched cards were waxed, so they stood up surprisingly well to humidity. What they didn't like was sweaty hands, which seemed to contain enough oils and other things to break down the coating. In storage mould could be a bigger problem than humidity. I experienced a lot of card punch and reader failures, but actual damage to a card was usually the result of really bad handling by humans.

Plus you can drop the deck of cards.

Like Foghorn Leghorn's feathers, you should always keep cards numbered for just such an occasion.

Punched paper tape is less prone to those problems and is more compact.

My experience of punched tape is that it was much more likely to fail you than punch cards. Tape was certainly more compact, mostly due to the thinness of the media, but that made tape more fragile. Any screwup with feeding the tape to the reader could result in a difficult to repair rip, and the readers were not great at handling the incoming and outgoing tape. Humidity and mould issues were also a bigger problem for the tapes I stored, than for the punched cards. The media I really cared about was stored in good conditions, but I also had quite a bit stored poorly.

[Mr. Scram]

I wonder how does a QR codes engraved on glass or stainless steel fare?

It's already a problem to have data preserved, but no means to read them. There have been instances of governmental agencies having lots of information stored on floppy disks, but not having any systems that can actually read it.

[tggzzz]

Punched paper tape is less prone to those problems and is more compact.

My experience of punched tape is that it was much more likely to fail you than punch cards. Tape was certainly more compact, mostly due to the thinness of the media, but that made tape more fragile. Any screwup with feeding the tape to the reader could result in a difficult to repair rip, and the readers were not great at handling the incoming and outgoing tape. Humidity and mould issues were also a bigger problem for the tapes I stored, than for the punched cards. The media I really cared about was stored in good conditions, but I also had quite a bit stored poorly.

I have effectively zero experience with punch cards. My experience with paper tape was wonderful - no problems whatsoever.

My final year project was "stored" on paper tape and read in at the beginning of every assembly session with a 1000cps reader. That was a sight to behold, spewing the tape 6ft into a bucket but still being able to stop instantly (i.e. within 1 character).

The object code was inserted into the SBC via an ASR33. I would have thought that dragging it through by its sprocket holes would have caused problems, but I don't remember any.

[coppice]

My final year project was "stored" on paper tape and read in at the beginning of every assembly session with a 1000cps reader. That was a sight to behold, spewing the tape 6ft into a bucket but still being able to stop instantly (i.e. within 1 character).

Those 1000cps reader were certainly a wonder to watch operating in burst mode. I always found it strange they didn't put more effort into the effective spooling of the tape.

The object code was inserted into the SBC via an ASR33. I would have thought that dragging it through by its sprocket holes would have caused problems, but I don't remember any.

If anything snagged the tape, an ASR33 would rip through the sprocket holes, and the ASR33 had no provision for spooling the tape at all.

[legacy]

back to harddrivs. This:

is a cause

[RoGeorge]

Never found inside a HDD something that covers half of the plate(s), like the curved piece of metal that covers almost half of the HDD plate in the above movie.

What it is, and mostly why it is there that shield like a semicircle metallic sheet? What's its role?

[julianhigginson]

That means (114-3/114) >> 90% of evidences in resulting "working" in a window of 20 years!!! Probably they won't last more, but the MBTF of modern electro-mechanical-ones says they will last more than 50 years.

MTBF is a statistical measure and is relevant when you are looking at LOTS OF instances of a component over a relatively small window of time.

The advised MTBF of a component does not equal life expectancy at all.

[julianhigginson]

anyway - back to the real discussion:

1) everything we do is written in sand. eventually it'll all wash away. It's not a matter of *if* your work will ever be unrecoverable, it's a matter of when. The best we can hope for is it'll be irrelevant to anyone before then.

2) long term source code management is becoming a "solved problem" now we have a giant worldwide computer network and configuration management repositories (at least until that orange baboon's net neutrality change cuts the internet into a bunch of walled gardens...) if you can keep your basic source code in a git repo, you can maintain it indefinitely on the internet, as long as you make sure it never gets forgotten about, and left on something that ends up deleted one day.

3) the other side of being able to use source files is the biggest issue because of tools that have limits... some limits were unforseen (code was only written to work on a certain type of computer, then code maintainer goes broke and no more builds can be made, then computer manufacturer changes something, and code won't run on their new computer... ) others are deliberate (time based licensing, encrypted files, etc etc) It seems to me like computers have "normalised" a bit recently, the hardware is becoming more consistent and changes aren't happening that fast anymore... OS changes seem a lot more abrupt lately.. maybe they will settle down eventually too?

If you are doing simple embedded development where you use a GCC based toolset for simple cross compilation (even something like atollic!) you always have the basic compiler that can be rebuilt from source, which takes us back to the "solved" source availability problem  (as long as you always have a compiler that can compile that!) so if you really need to, you can make an environment to build that code again... and hopefully find a way to get it from that environment to wherever it needs to go.

But when you are building a *system* that has custom code, but is also based on a full blown OS like linux with a  bunch of packages from all over the place, then as explained above, there's a whole world of hell with package compatibility (mostly because linux people just change things for the sake of changing things and break compatibility all the time -  the reason why linux is *still* not a reasonable choice for desktop purposes, for someone who just wants to use a computer to do work)

Personally, for any project I do, I document and archive the toolchain (note versions of everything, save copies of install files, write complete install instructions) as a minimum. Then for a project that undergoes development over time, I take the time to update that toolchain (AND THE DOCS)  as I go, but only when the project hits a milestone, and I have time to baseline/compare/verify the update.. this also gives a chance to migrate other parts of the toolchain (OS, etc, debug probes if necessary) and seems the best approach to have a standard build setup, but always be in the best position to have something re-creatable at some point in the future, once the project goes into long term hibernation.... at hibernation, if a project has a VM to do the development like I have had in the past and may again in the future, then I might also save that VM (but no guarantee it'll work in future..)

[nctnico]

If you are doing simple embedded development where you use a GCC based toolset for simple cross compilation (even something like atollic!) you always have the basic compiler that can be rebuilt from source, which takes us back to the "solved" source availability problem  (as long as you always have a compiler that can compile that!) so if you really need to, you can make an environment to build that code again... and hopefully find a way to get it from that environment to wherever it needs to go.

But when you are building a *system* that has custom code, but is also based on a full blown OS like linux with a  bunch of packages from all over the place, then as explained above, there's a whole world of hell with package compatibility (mostly because linux people just change things for the sake of changing things and break compatibility all the time -  the reason why linux is *still* not a reasonable choice for desktop purposes, for someone who just wants to use a computer to do work)

The last paragraph doesn't line up with the first one. You can freeze an embedded Linux distribution the same way you described for a 'simple embedded' project (been there, done that).

[julianhigginson]

The last paragraph doesn't line up with the first one. You can freeze an embedded Linux distribution the same way you described for a 'simple embedded' project (been there, done that).

fair enough - it's always seemed a lot more hassle when I've seen it attempted...

[lundmar]

VM is definitely the way to go if you want to preserve your work environment for many years. Just make sure to use save your VM disk in standardized open formats like VMDK as these are more likely to be supported by future VM implementations.