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!
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
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.
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.
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.
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.)
I wonder how does a QR codes engraved on glass or stainless steel fare?
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.
LoTek steampunkoh, 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
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
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.
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?
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.
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.
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.
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.
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.
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?
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.
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..)
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).
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...
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.