| |||||||||||||
On text documentsOn text documentsPosted May 13, 2012 22:29 UTC (Sun) by giraffedata (subscriber, #1954)In reply to: On text documents by apoelstra Parent article: Who owns your data?
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".
(Log in to post comments)
On text documents Posted May 13, 2012 22:54 UTC (Sun) by apoelstra (subscriber, #75205) [Link]
I was being somewhat tongue-in-cheek, but here is an example of what I meant:
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...
On text documents Posted May 14, 2012 13:00 UTC (Mon) by philipstorry (subscriber, #45926) [Link]
I see your point, but I think we can circumvent some of this.
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.
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.)
On text documents Posted May 14, 2012 13:19 UTC (Mon) by paulj (subscriber, #341) [Link]
I think you've missed their point. Switching to, say, QEMU and software-virtualisation doesn't solve things. Eventually one day QEMU will no longer be maintained. Some time after that, the systems on which QEMU runs (software and hardware wise) will be obsolete. You will then have to run a VM of the system on which QEMU runs, in order to be able to run QEMU, in order to run the VM that contains the software you need to run in order to view the document you're interested in. Even that new system will eventually one day become obsolete, necessitating another layer of VMs. You end up with VM turtles all the way down.
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..
|
|||||||||||||