Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
On text documents
Posted May 13, 2012 22:29 UTC (Sun) by giraffedata (subscriber, #1954)
When your OS no longer supports the VM you want, you should just run an
old version in a VM, so your document will be on a VM-within-a-VM. Then
eventually you'll need a VM-within-a-VM-within-a-VM, and so on...
I can't tell what you're describing. Can you phrase this without the word "support" so it's more precise?
I'm also unclear on what "the VM you want" is and whether when you say OS, you're talking about a particular instance or a class such as "Fedora".
Posted May 13, 2012 22:54 UTC (Sun) by apoelstra (subscriber, #75205)
Suppose your documents live in Wordstar for windows 3.1. So you keep Windows 3.1/MS-DOS 5 on a VM for a while. But one day you wake up to Windows 7, and it's 64-bit only, and won't your old DOS-supporting VM software anymore.
(I don't know if this is actually a problem. It's just an example.)
So you go ahead and install XP in a VM under Windows 7. On XP, you run a VM containing DOS, on which you run Wordstar.
Some years later, XP won't run on a VM since it's 2045 and nobody has heard of BIOS anymore. So you have a VM running Win7, which runs a VM running XP, which runs a VM running DOS, which finally runs Wordstar.
Then 25 years later, your VM software doesn't work, so you add another layer...
Posted May 14, 2012 13:00 UTC (Mon) by philipstorry (subscriber, #45926)
I think that at some point - probably host-architecture bound - we have to switch from VM-as-supervisor to straight emulation.
I've mentioned this in another reply, so apologies if you've read it already - but basically, when your VM solution finally stops supporting your version of the client OS then it's time to look at a switch to emulating the entire machine, QEMU style.
The advantage of that is that the emulation is much more likely to last longer, albeit be somewhat slower to run.
The Intel/AMD 64-bit chips are (I believe) incapable of running 16-bit code when in 64-bit mode. They can run 32-bit, just not 16-bit.
So we're already at the point where VM systems are unable to run some old OSes or apps without resorting to emulation behind the scenes.
Rather than rely on that assumed emulation, I think we should build in a stage where we simple say "all 16-bit code is emulated", and prepare for the idea that 128-bit processors in a decade or two might mean we have to add 32-bit code to the "emulated by default" pile.
That stops us from having to do VMs within VMs, as you describe. (And if the chip won't run the code, and there's no emulator, I'm not sure VMs within VMs will work anyway.)
Posted May 14, 2012 13:19 UTC (Mon) by paulj (subscriber, #341)
Further, you are assuming that for every such system that becomes obsolete there will be a VM on the newer system to run the older system. This is far from guaranteed. If that assumption ever fails, access to that document is lost after that time. For that assumption to always be true, every system needs to be sufficiently well documented by its maker that someone in the future will be able to emulate it. I.e. it assumes your chain of VMs will never become dependent on a monolithically proprietary system.
So, given that your VM system also relies on open specifications, wouldn't it be much better & simpler to just work towards ensuring documents are stored in openly specified formats? That seems far more future proof to me..
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds