Don't Nurse Old Hardware - Emulate It 403
gManZboy writes "Bob Supnik, former team lead for DEC's VAX microprossesor, has an article up on Queue about his Computer History Simulation Project and how emulating old servers may be a better way to keep them running that servicing the physical machines. So how many PDP-11's can you run on a Pentium 4 anyhow?"
Can't believe no one's thought of this (Score:3, Insightful)
Emulation is great .. (Score:5, Insightful)
Good idea... but... (Score:5, Insightful)
How are you going to emulate a 5.25 inch drive to read old disks?
The Stability of New Products vs Old (Score:5, Insightful)
By using the original the kinks have already been worked out, quirks are known and understood, and everything just works.
By creating an emulator you have bugs to smash, that's just the way software is. Also keep in mind this seems to apply to big businesses (financial, medical) and large organizations (NASA) with legacy hardware. Since the stability of these systems is absolutely crucial why would they want to switch to a new, unproven, buggy system that stick with the old?
DEC VAX -- why not port?! (Score:2, Insightful)
I wonder why... (Score:5, Insightful)
Gee, I wonder why he would be recommending buying new servers?
More important question: (Score:3, Insightful)
Re:Good idea... but... (Score:2, Insightful)
Re:legal issues? (Score:1, Insightful)
Re:Can't believe no one's thought of this (Score:5, Insightful)
Re:DEC VAX -- why not port?! (Score:5, Insightful)
Methinks you underestimate how badly software projects of that sort often go.
Re:Emulation is great .. (Score:5, Insightful)
efficient versus speed (Score:3, Insightful)
Hardware stability is a problem (Score:1, Insightful)
On a digression, it was great working for Bob Supnick. He's a nice, bright guy and I'm glad to see he's still keeping things stirred up.
Re:DEC VAX -- why not port?! (Score:2, Insightful)
An upgrade path could be way overdue
Why not port? Why bother? (Score:3, Insightful)
In this situation, you could spend a couple of thousand dollars on a new machine and run your old software on it using a free emulator. Hell, the machine you just ordered for your secretary would probably out-perform the old server. The new machine will be one twentieth the size of the old, use one twentieth of the electricity and won't have twenty years of accumulated wear and tear.
If you've got a custom application written in a dead language, emulation may be the best way to continue fulfilling your requirements too. Sure, a new app in the shiny new language du jour might be nice, but if you've got proven 30 year old code and performance on the old hardware is adequate then it makes sense to keep things ticking on a virtual vax or pdp. And think of the kind of server room consolidation you could perform!
Other posters have commented on the proven behaviour of hardware v. emulators - how the latter could have bugs that aren't apparant, and may thus be unsuitable for users like NASA etc. Surely it's easier to produce a bug-for-bug compatible emulator than it is to re-write possibly millions of lines of legacy code in a bug-free manner. Sure, it's nice in the long run to re-write software with greater portability in mind, but while that's happening wouldn't it be worth making sure you can continue to run your existing programs without having to worry what will happen if some obscure I.C. elects a new Pope?
Re:Can't believe no one's thought of this (Score:4, Insightful)
Re:Please explain again.... (Score:1, Insightful)
Re:DEC VAX -- why not port?! (Score:2, Insightful)
1. Uptime on linux/unix is not good enough. Linux/Unix versus Microsoft, sure its got a better uptime, but against a mainframe that hasn't been turned off in 20-30 years? We're not talking commodity hardware here that'll break in a few years, or need constant replacing. Banks, hospitals, etc can't afford any down time.
2. The code is probably long gone, and the software was probably custom. So, how exactly are you going to "port" this software? Oh, I know, tell all those banks to use gnucash.
3. If it ain't broke, don't fix it. All their employees know how it works. All their sys admins know the quirks. If you move to a new system, you've got thousands of employees who have to learn the new system from sys admins who don't know the software.
When it comes to upgrading a mainframe, its not like upgrading your home computer or home file server. You don't simply copy your ~/ over to your new computer and start running firefox.
Re:I wonder why... (Score:3, Insightful)
And while I hope it never happens to you, if you happen to get into hospital, there is quite some chance that your information will be registered on a.... VAX. that is right, an old, according to you obviously unusable VAX.
Next time you transfer some money, chances are quite good that your order will be processed by... again one of those unusable vaxen...
I suggest you delve a bit into the matter before laughing your ass off because this makes you look like someone who knows very little of what is being used.
Re:The Stability of New Products vs Old (Score:5, Insightful)
Re:The Stability of New Products vs Old (Score:4, Insightful)
was used as the design "core" for Microsoft's
Windows NT. I have known of DEC VAX hardware
that ran continuously for 5 years without a
warm reboot, let alone a system shutdown. The
Microsoft OS often needed to be rebooted daily.
The hardware that Microsoft runs on is not as
reliable as the old DEC VAXs, as a rule. The
short term emulation of a legacy system is not
the same as replacing it. For exammple, an IBM
z/390 running MVS might be able to run 1000
linux servers, but in terms of reliability
(the proverbial 5 Nines), that z/390 could not
be replaced with 1000 linux boxes, or even 2000.
The old adage "They just don't make things the
way they used to." applies here. New hardware
costs are way down, as are HW/SW maintenence
costs, but the reliability of the new gear is
underwhelming.
Re:Can't believe no one's thought of this (Score:3, Insightful)
I agree! (Score:2, Insightful)
Just think of the possibilities! Why try to preserve the Mona Lisa, when we can just photocopy it?
David the statue? Laser scan it, and upload the mesh triangles to sourceforge!
There is nothing that this strategy can't be used on for outrageous savings. We don't even have to manufacture new CPUs at all, just emulate the Pentium5 on your PII!
Emulation is for those that go "Gee, wasn't that nifty", once in their lifetimes. The true enthusiast wants the real thing. If someone restores old cars, they're an auto enthusiast, and people honk their horns at the things on the road, in admiration. If it's home furnishings, they're antique collectors, and magazines do photoshoots of the treasures. But if it's a computer, you were supposed to throw that out after 6 months, to buy another. It makes no sense.
Re:I agree! (Score:4, Insightful)
They end up with still failing "virtual" hardware, and the only consolation is that if they persist long enough, they may eventually fix it completely. Oh, at least until they need to port the emulator to Windows 2009 Gold Pro edition on the Pentium 9, then it bugs out again.
Start porting the damn apps, or rewrite them. And even as you're doing this, plan for the next changeover in 10-15 years.
Why: Coolness and Bootstrap Education (Score:2, Insightful)
A big one (not the one that funds them) is they are cool.
Useful sometimes. E.g. PDP-11 on a PCI board with a PDP-11 hardware interface is buyable. It's used, among other places, in the postal system to run hardware that needs a PDP-11. Interestingly, it used to use the PDP-11 on a chip but last I checked used an Intel CPU. XEROX had allegedly bought all the remaining PDP-11 on a chip machines for their use in copiers.
The article was pushing the "where we came from" aspects. I KNOW how hard it is to keep PDP-10 hardware running. It's rather handy in defeating patents to come up with prior art...from, say, 1964. The thing here is it's use it or lose it time. You write an emulator and you understand the machine.
Bootstrap Education. A young person can understand a CP/M machine on a level that just isn't going to happen, say, my iBook G4 and use that understanding to bootstrap up to the next level of complexity.
Re:Can't believe no one's thought of this (Score:4, Insightful)
So you emulate those, as well... And usually, they take a lot less to emulate than the core system.
As a trivial example, consider the peripherals available even on previous-gen consoles... You have 3rd party joysticks, mice, keyboards, cameras, tape drives, printers(?), etc. All those eventually end up emulated, if enough people needed them.
The same goes for something like a PDP-11 or VAX 11/750 or the like. You have some odd storage devices (that store a tiny fraction of modern HDDs, thus you can emulate them with an image file). You have printers (emulatable with... printers!). Perhaps really ancient input devices such as a cardreader (scanner -> conversion tool -> file). No doubt other exotic peripherals exist, but you can somehow emulate them all.
The conceptual problem with dealing with peripherals I think lies in just how much we've advanced since the days of Big Iron... Even for emulating CPU-cycle-critical hardware interactions, you can deal with it in emulation, by pure brute-force. Consider the 11/780, which ran at a whopping 6MHz. On a modern P4, that means you have over 500 CPU cycles per emulated cycle (and while the P4 can push through more than two ops per clock, the VAX only managed one instruction per 6(?) clocks, meaning you realistically have over six thousand real instructions per emulated one, on average). With six thousand instructions to burn, you could emulate your VAX while still getting a good framerate playing Super Metroid on an emulated SuperNes in the foreground.
That I know of, only the humble old laserdisc has thus far resisted attempts at perfect emulation, due to using an analog encoding scheme (rather than storing bits, it actually encoded the raw NTSC or PAL signal handled by the TV. And depending on what sort of access to them you need, even that problem has a way around it, via an MPEG rip and a frame file (ala Daphne).
Re:Can't believe no one's thought of this (Score:3, Insightful)
Fair enough point - But in that case, I would have to consider the computer secondary to the machine itself - I don't know your specific situation, but the computer most likely did data collection and analysis. The controller-proper I would consider part of the "peripheral", and search for the easiest-to-tap connection as the point to break away from reality and into emulation.
I'll admit, I hadn't considered that point. You can't emulate a fatigue testing machine. You can't emulate a GC/MS. You can't emulate a CNC. You can't emulate an MRI. But I see that as similar to saying you can't emulate a car... You could fake-out a car's computer, but it doesn't do much good without car itself. Apples and Oranges.
So no, emulation won't solve all obsolescence problems... But for those situations where you wouldn't consider the computer as secondary to the peripheral...
However - as I touched on above, you can almost certainly still replace the computer portion of the system. At some point, the computer just takes a digital input, and at that point, you make the split from reality. My car doesn't care if its own computer runs it, or a PC sitting in the passenger seat. That might not do much to reduce the maintenence costs of the primary machine involved, but it does mean you can have your data on something other than an ancient reel-to-reel...