Presumably they would have separate NICs. Since the insecure VM is still a VM, the host can also control the events it is able to sniff.
Even timing attacks can be counteracted by introducing pseudorandom clock skew (a-la GPS) in the virtual machines. You just wouldn't be able to run any software that couldn't cope with the clock running backwards sometimes...
This is a really good point; if the image from a running secure VM is captured, it will necessarily have any session keys in its memory.
However, these session keys are not the same as the (presumably) strong master key used to generate them. Many programs (such as PGP) go to great lengths to destroy the memory-representation of my master key after it is no longer needed -- tho this is mainly to avoid it being swapped to disk.
Other workarounds are keeping the master keys in hardware -- the NIC or in one of the IBM hardware locks. Neither of these are part of the VM state, but rather the base hardware, so they wouldn't be represented in the secure VM.
Another idea would be to have the Host do these as a trap -- have the secure VM think its running on hardware with an de/encryption primitive instruction. This instruction is trapped by the VMWare and executed by the host operating system.
In this last case, compromising the host would imply key loss; this is not necessarily the case in the hardware scenario.
If you compromise the internet VM (which we assume can happen -- this is why they are currently different machines, physically) this doesn't necessarily give you any means to access the meta level Host computer.
If that were possible, then yes, the attacker could compromise the supposedly secure intra-net VM (NB: copying its state would only give you a snapshot -- it would be much better just to relay all of its communication traffic to the internet).
So now we need to prove that it is impossible to get access to the meta level from the internet. This comes immediately from the virtualisation requirements -- each hosted OS has no way of realising it isn't running on the base hardware.
Even if we are not able to prove this, the fact that the internet connected machine is virtual gives us the abilty to snapshot its state at a fully booted uncompromised point in time; In order to make cracking it hard, we can just kill the entire machine every 5 minutes and reinstate the snapshotted version. Any attacker now has to crack not only the inter-net VM, but also the Host machine in 5 minutes.
However, this all assumes a trusted user. If the user has the ability to do screen captures from the intra-net VM, they could then conveniently send these via the inter-net VM.
A better test would have been to use -j2 for a single CPU. You want something for the processor to do while the disk is spinning. Spawning three processes just increases contention for resources on a single CPU without really buying you anything.
Basically, any supra-linear speedup makes me worry -- I'm willing to believe a bit of superlinearity from preloaded disk caches and what not, but 142% is quite a bit more than I can accept at face value.
Spinning up and down the drives is one thing, but there are other ways to save power. Many CPUs are able to micro-sleep (basically halt their clock) so they retain complete state (incl cache?). Any interrupt wakes them up. Even if it takes a couple of thousand cycles to come up to speed, this is plenty fast to respond to any external situation (*).
Appart from heat expansion/contraction, I don't see that this could add any wear or tear to the computer. In fact, as the cpu will tend to run cooler, this might be a good thing in general.
(*) if your computer can run a quarter of a second on the juice in the power-supply's capacitors after you yank the plug, this is something like 250 million cycles on a modern cpu. And I doubt it takes the cpu 1000 cycles to wake from a halted clock.
I had a look at the page (it's http://www.indrema.com, btw) and it seems that the box will 1) support SDMI 2) require certification of all software it runs 3) have proprietary (ie, non-open) drivers for its hardware.
These (esp #1 and #2) seem to (although this is my conclusion) require that the end user not be given the root password. Of course, I could always just remove the harddrive to another machine to circumvent, but #1,#2 above would make this illegal.
I don't know how comfortable I'd be with a full-fledged internet-connected computer in my home with access to my viewing habits to which I am not root (thus preventing me from turning off services, for example).
There's also a semantic difference. In the backquoted case, the backquoted command is completely evaluated 'till completion, and only then is the resulting command line executed.
The | xargs approach is more incremental, producing output before the find is completed.
This normally doesn't make a difference, but if find is slow, you only want the first few lines of output (stop at first hit), or find never terminates, the pipe is a better solution.
Perhaps you misunderstood what the original poster meant by other languages. I understood that (s)he intended other languages compiled to the same VM. Native code is out of the question in any sort of distributed environment (can't be propagated over the net due to security concerns, different hardware...).
Of course, there are (as other posters have pointed out) any number of langauge that target the java virtual machine. The Java part of the name is important; there such a close correspondance to the Java source language that there's [almost] a one-to-one mapping between.class and.java files. Thus, compiling to the JVM is about as much work as compiling to java, and as anyone will tell you, a source-to-source translation between languages is hard to make efficient in the general case.
The upshot is that languages such as Python, ML, Scheme, or Ada that have been targeted to the JVM, need several tricks and restrictions to make them usably fast..NET was implemented in a langauge agnostic manner, which makes the compiler-writer's job harder for Java, but easier for every other language in the world. There's even a tail-call instruction for functional langauges, put in at the request of the brights at Microsoft Research.
Readers of comp.compilers would argue that.NET is microsoft's attempt at implementing UNCOL, the fabled universal intermediate language for compilers. Quoth John Levine comp.compilers moderator:
The traditional term for such a language is UNCOL, the name of the
first such project that failed in the 1950s. There have been a lot of
UNCOL projects over the years and they've all failed because nobody's
been able to capture the semantics of all programming languages and all
target architectures in a way that is abstract enough that you don't end
up with a pile of special hacks for each source language yet concrete
enough that you can produce efficient target programs. I suspect that the
range of supporting environments is as much of a problem as the order code,
e.g. consider a system that has to support Cobol and Lisp.
He's a smart man, and seems to think it will fail miserably. But microsoft have hired several smart men, and perhaps they can pull it off.
meta: I have no idea why this was posted as AC. T'was me, I swear
Image recognition?
good idea. If the vantage points are close enough togeter, you might be able to reuse image stabilation techniques to aim all cameras at the same subject-of-interest. This would be possible because if the cameras are "close enough" software should be able to indentify a figure from one camera in the next camera's field of view. Then this can be used as input to the next camera...
Mind you, I suspect that they use a combination of the two; special purpose hardware to sense where the master camera is pointing (using both focus, zoom, and the heuristic that most action is on the ground -- allowing you to infer the voxel being targeted by the intersection of the ground with the FoV of the master camera) and image recognition to "register" (to use a medical term) the various images on the PoI.
If you look closely, they also choose which character to use depending on local line features. So you have 4 bits color, 4 bits char choice (just to throw out some numbers).
Arguably, they would be better off with a 2x2 pixel x 2 bit grey decomposition, from a pure fidelity point of view, but using ascii is really cool. I was actually a bit dissapointed there was grey-scale at all. Just using different chars for that (".+*" for light through dark grey, "|-\/" for edge features, f.ex) would have been cooler, IMANHO.
Ah, so that's how they do the slow motion they were discussing. I had understood how the CBS system worked, but I couldn't see how the Matrix system did anything but time-freeze (BTW, all these discussions would benefit from asc-ii art, but that is apparently "lame" according to slashdot).
I seem to recall their test system consisting of 16 cameras, but the real deployment will consist of 33, spaced irregularly. I too noticed the jerkiness, which is why I proposed using morphing in panning the virtual camera. The REAL solution is of course to do [partial] 3-d interpretation which would give you even more possible virtual camera locations.
Do you know how they will aim the cameras (including coordinating Zooming?) I can visualise a system where a circle is dragged around the field on a computer monitor (it's radius signifies zoom), but this seems hard to use to follow the action. Do they have some sort of automatic target tracking? Or some semi-smart slaving ot a main camera (in which case the focus of the main camera would be used to clue the slaves where to pan along the line-of-sight of the main)?
and this is a Good Thing(*). I propose to you that faster processors are not encouraging bloatware, but rather enabling more complex applications to be build. In a way, upgrading processors is a Computer Tax. It goes indirectly to software companies by making constructing large apps cheaper.
Applications are much larger now than they were before. In order to effectively build large applications, you need abstraction. Abstraction is the enemy of buffed code. Of course, we always hope that compiler technology and coding wizardry (ever see code speed up by a factor of two after adding a few inline pragmas?) will claw back performance, but it is clearly the case that we need to increase processor speed for one main reason: to pay for increased levels of abstraction.
After all, my 1 Mhz Z-80 card for the Apple II ran wordstar just fine, so why do I need a 500 Mhz PIII to run Office 2000? Because Office does so much more. Of course it's huge and overwrought, but that is a side-effect of the programming technologies that allowed it to be built at all, not evidence of shoddy construction. Taken to an extreme, I wonder whether it would be in the interest of large software houses to subsidize processor upgrades. hrm.
An interesting economic question: are we better of with this indirect software tax, or would the world as a whole be better off if Office cost more but ran on lower end hardware?
I posit that we are better off now; the trickle down effects from advancing chip technology benefit all and all software can take advantage of fast chips. Furthermore, if software were efficient, this would not drive semi-conductor innovations, and you would have very expensive hardware that runs more slowly than it does now.
Basically, I suspect the bloatware or buffware scenarios would have similar total costs to the end consumer, but bloatware additionally drives semi-conductor innovation, which benefits everyone in the world. The same resources spent on better software engineering tools to make buffware would only benefit software houses.
Lastly, let me conclude with the most exciting technology out there now: dynamic optimization.
This technology (exemplified by Dynamo, CodeMorphing, and JITs) has the potential to optimise away the speed penalties inherent in modular software, by discovering stable software configurations at runtime (f.ex inlining library code, removing indirection in COM method calls, specialiasing common cases).
(*) Of course asymptotic inefficiency is never warranted, but a constant factor slowdown may be. Of course there will always be tight loops to be programmed in assembly/C but 95% of the time, investing the resources to upgrade the client hardware is a better idea.
I had just assumed that it would be done by having multiple cameras -- synchronised during cutting and morphing by a timing track, to produce movement of the virtual camera through time/space ('cause space/time is overused) -- but they seem to have a two film system which can either freeze location (to one of a few predetermined spots) or freeze time at one instant. After time has been frozen once, you then need to wind that film through ALL those cameras before it can be done again.
It seems that the NFL have developed a significantly better system. Theirs seems to allow unconstrained motion in time/space -- thus you could imagine a shot panning along during [slow] motion of the subject. IIRC, we never saw this in the matrix; there the motion was always completely frozen when the camera moved.
I believe that the technology popularised by the Matrix (and used before that in several commercials) is already patented. A brief search on google failed to confirm this, tho.
As for the erasing part, that is pretty cool, technically; they'd have to pretty much incorporate all the visual inputs into one 3d interpretation of the scene, and then recreate the scene from the desired viewpoint. I had no idea that 3d visual research was that far advanced. Or can anyone suggest a Q-n-D approach?
Well, in that case, why not just relocate the farm to somewhere cold and close to a power plant; you get airconditioning for free (open the window, eh?) and electricity is availible. If opening the window isn't an option, land should be cheap enough so that you can afford to space your servers out a bit.
and you can now stop leasing expensive california real estate.
That lameness filter truly does suck. It's kinda self-referential in that way.
I tried to suggest that slashcode be modified so that users with enought karma could override the lameness filter (at least for ASCII-art), but was given a polite shove back the way I came.
things are getting better; no longer can sequences be blindly patented without knowing what they do (this was previously possible -- I have no idea what they were smoking when they dreamt that one up).
So now there actually is a little bit more discovery necessary than the straight output of a DNA sequencer. I kinda think that the exact location of the gene that turns on cancer would be a valid patent. So you patent the understanding of the funtion, not the genes themselves.
I dunno that the feature size is that much of a killer. I think we can claw back the low-clock rate by massive integration.
There's a lot of inefficiency inherent in the modular assembly process exemplified by your run-of-the-mill laptop. The processor talks to memory over a small bus, the hard-drive knows little of what will be requested next...
This is all the case because traditional manufacuring needs to modularise in order to acheive high enough yeilds to be price-effective. Hence each component needs to be a fast as possible (thus the smaller feature size) to achieve acceptable performance.
If the entire logic circuit of the laptop could be printed in one go -- Extrelemely Large Scale Integrationed -- I'd imagine that we could compensate for the lower clock speed by exploiting paralellism and asycn clocking. Instead of printing only one CPU, print ten, each with their own memory. Give 'em a nice wide bus to communicate...
Of course, no-one said that designing or programming this beast would be easy.
Would that it were not the case, but I suspect that the video licences are royalty based. This would work fine if RedHat sold each copy of its product, but since any yahoo can download it off their website, that seems to be a real killer (road kill on the superhighway, to torture your analogy).
Maybe a third party could sell the player, but we all know how well payware fares in the linux comunity.
fair 'nuff. I've often conscidered getting a tape drive, but can ill afford the IDE slot (SCSI is not an option for economic reasons). What I should do is reshuffle my drives to make a smallish raid mirrored partition (is that raid-0?) for my important work and run something fun on the the rest of the drives.
Unfortunately, my sys admin skills are unexceptional. I can't even make NFS work after restoring my file server to RedHat 2.2.16 compliance. I need to free up a weekend to fix this, but it's ski season, and a man's got to have priorities.
Slashdot Mirror
These results would imply that I/O is a serious bottleneck, so I'm not sure how that squares with the assumption of optimisation being a major cost.
Any thoughts?
Presumably they would have separate NICs. Since the insecure VM is still a VM, the host can also control the events it is able to sniff.
Even timing attacks can be counteracted by introducing pseudorandom clock skew (a-la GPS) in the virtual machines. You just wouldn't be able to run any software that couldn't cope with the clock running backwards sometimes...
This is a really good point; if the image from a running secure VM is captured, it will necessarily have any session keys in its memory.
However, these session keys are not the same as the (presumably) strong master key used to generate them. Many programs (such as PGP) go to great lengths to destroy the memory-representation of my master key after it is no longer needed -- tho this is mainly to avoid it being swapped to disk.
Other workarounds are keeping the master keys in hardware -- the NIC or in one of the IBM hardware locks. Neither of these are part of the VM state, but rather the base hardware, so they wouldn't be represented in the secure VM.
Another idea would be to have the Host do these as a trap -- have the secure VM think its running on hardware with an de/encryption primitive instruction. This instruction is trapped by the VMWare and executed by the host operating system.
In this last case, compromising the host would imply key loss; this is not necessarily the case in the hardware scenario.
The point is that you have 3 systems running:
Host
/ \
inter- intra-
net VM net VM
If you compromise the internet VM (which we assume can happen -- this is why they are currently different machines, physically) this doesn't necessarily give you any means to access the meta level Host computer.
If that were possible, then yes, the attacker could compromise the supposedly secure intra-net VM (NB: copying its state would only give you a snapshot -- it would be much better just to relay all of its communication traffic to the internet).
So now we need to prove that it is impossible to get access to the meta level from the internet. This comes immediately from the virtualisation requirements -- each hosted OS has no way of realising it isn't running on the base hardware.
Even if we are not able to prove this, the fact that the internet connected machine is virtual gives us the abilty to snapshot its state at a fully booted uncompromised point in time; In order to make cracking it hard, we can just kill the entire machine every 5 minutes and reinstate the snapshotted version. Any attacker now has to crack not only the inter-net VM, but also the Host machine in 5 minutes.
However, this all assumes a trusted user. If the user has the ability to do screen captures from the intra-net VM, they could then conveniently send these via the inter-net VM.
A better test would have been to use -j2 for a single CPU. You want something for the processor to do while the disk is spinning. Spawning three processes just increases contention for resources on a single CPU without really buying you anything.
Basically, any supra-linear speedup makes me worry -- I'm willing to believe a bit of superlinearity from preloaded disk caches and what not, but 142% is quite a bit more than I can accept at face value.
yup. all this really shows is that new athlons are so fast that compilation is I/O bound.
I wonder how fast one could make a compiler if it were persistent, so that all the common #includes didn't need to be reparsed for every source file.
Spinning up and down the drives is one thing, but there are other ways to save power. Many CPUs are able to micro-sleep (basically halt their clock) so they retain complete state (incl cache?). Any interrupt wakes them up. Even if it takes a couple of thousand cycles to come up to speed, this is plenty fast to respond to any external situation (*).
Appart from heat expansion/contraction, I don't see that this could add any wear or tear to the computer. In fact, as the cpu will tend to run cooler, this might be a good thing in general.
(*) if your computer can run a quarter of a second on the juice in the power-supply's capacitors after you yank the plug, this is something like 250 million cycles on a modern cpu. And I doubt it takes the cpu 1000 cycles to wake from a halted clock.
I had a look at the page (it's http://www.indrema.com, btw) and it seems that the box will 1) support SDMI 2) require certification of all software it runs 3) have proprietary (ie, non-open) drivers for its hardware.
These (esp #1 and #2) seem to (although this is my conclusion) require that the end user not be given the root password. Of course, I could always just remove the harddrive to another machine to circumvent, but #1,#2 above would make this illegal.
I don't know how comfortable I'd be with a full-fledged internet-connected computer in my home with access to my viewing habits to which I am not root (thus preventing me from turning off services, for example).
It is one of the common combinations to try before giving up, along with /, anonymous/email@ddre.ss, anonymous/coward, and cypherpunks/cypherpunks.
(the latter has failed to work recently -- does anyone know whether it has been killfiled?)
There's also a semantic difference. In the backquoted case, the backquoted command is completely evaluated 'till completion, and only then is the resulting command line executed.
The | xargs approach is more incremental, producing output before the find is completed.
This normally doesn't make a difference, but if find is slow, you only want the first few lines of output (stop at first hit), or find never terminates, the pipe is a better solution.
Perhaps you misunderstood what the original poster meant by other languages. I understood that (s)he intended other languages compiled to the same VM. Native code is out of the question in any sort of distributed environment (can't be propagated over the net due to security concerns, different hardware...).
Of course, there are (as other posters have pointed out) any number of langauge that target the java virtual machine. The Java part of the name is important; there such a close correspondance to the Java source language that there's [almost] a one-to-one mapping between
The upshot is that languages such as Python, ML, Scheme, or Ada that have been targeted to the JVM, need several tricks and restrictions to make them usably fast.
Readers of comp.compilers would argue that
He's a smart man, and seems to think it will fail miserably. But microsoft have hired several smart men, and perhaps they can pull it off.
meta: I have no idea why this was posted as AC. T'was me, I swear
Image recognition?
good idea. If the vantage points are close enough togeter, you might be able to reuse image stabilation techniques to aim all cameras at the same subject-of-interest. This would be possible because if the cameras are "close enough" software should be able to indentify a figure from one camera in the next camera's field of view. Then this can be used as input to the next camera...
Mind you, I suspect that they use a combination of the two; special purpose hardware to sense where the master camera is pointing (using both focus, zoom, and the heuristic that most action is on the ground -- allowing you to infer the voxel being targeted by the intersection of the ground with the FoV of the master camera) and image recognition to "register" (to use a medical term) the various images on the PoI.
If you look closely, they also choose which character to use depending on local line features. So you have 4 bits color, 4 bits char choice (just to throw out some numbers).
Arguably, they would be better off with a 2x2 pixel x 2 bit grey decomposition, from a pure fidelity point of view, but using ascii is really cool. I was actually a bit dissapointed there was grey-scale at all. Just using different chars for that (".+*" for light through dark grey, "|-\/" for edge features, f.ex) would have been cooler, IMANHO.
Ah, so that's how they do the slow motion they were discussing. I had understood how the CBS system worked, but I couldn't see how the Matrix system did anything but time-freeze (BTW, all these discussions would benefit from asc-ii art, but that is apparently "lame" according to slashdot).
I seem to recall their test system consisting of 16 cameras, but the real deployment will consist of 33, spaced irregularly. I too noticed the jerkiness, which is why I proposed using morphing in panning the virtual camera. The REAL solution is of course to do [partial] 3-d interpretation which would give you even more possible virtual camera locations.
Do you know how they will aim the cameras (including coordinating Zooming?) I can visualise a system where a circle is dragged around the field on a computer monitor (it's radius signifies zoom), but this seems hard to use to follow the action. Do they have some sort of automatic target tracking? Or some semi-smart slaving ot a main camera (in which case the focus of the main camera would be used to clue the slaves where to pan along the line-of-sight of the main)?
yes!
and this is a Good Thing(*). I propose to you that faster processors are not encouraging bloatware, but rather enabling more complex applications to be build. In a way, upgrading processors is a Computer Tax. It goes indirectly to software companies by making constructing large apps cheaper.
Applications are much larger now than they were before. In order to effectively build large applications, you need abstraction. Abstraction is the enemy of buffed code. Of course, we always hope that compiler technology and coding wizardry (ever see code speed up by a factor of two after adding a few inline pragmas?) will claw back performance, but it is clearly the case that we need to increase processor speed for one main reason: to pay for increased levels of abstraction.
After all, my 1 Mhz Z-80 card for the Apple II ran wordstar just fine, so why do I need a 500 Mhz PIII to run Office 2000? Because Office does so much more. Of course it's huge and overwrought, but that is a side-effect of the programming technologies that allowed it to be built at all, not evidence of shoddy construction. Taken to an extreme, I wonder whether it would be in the interest of large software houses to subsidize processor upgrades. hrm.
An interesting economic question: are we better of with this indirect software tax, or would the world as a whole be better off if Office cost more but ran on lower end hardware?
I posit that we are better off now; the trickle down effects from advancing chip technology benefit all and all software can take advantage of fast chips. Furthermore, if software were efficient, this would not drive semi-conductor innovations, and you would have very expensive hardware that runs more slowly than it does now.
Basically, I suspect the bloatware or buffware scenarios would have similar total costs to the end consumer, but bloatware additionally drives semi-conductor innovation, which benefits everyone in the world. The same resources spent on better software engineering tools to make buffware would only benefit software houses.
Lastly, let me conclude with the most exciting technology out there now: dynamic optimization.
This technology (exemplified by Dynamo, CodeMorphing, and JITs) has the potential to optimise away the speed penalties inherent in modular software, by discovering stable software configurations at runtime (f.ex inlining library code, removing indirection in COM method calls, specialiasing common cases).
(*) Of course asymptotic inefficiency is never warranted, but a constant factor slowdown may be. Of course there will always be tight loops to be programmed in assembly/C but 95% of the time, investing the resources to upgrade the client hardware is a better idea.
I had just assumed that it would be done by having multiple cameras -- synchronised during cutting and morphing by a timing track, to produce movement of the virtual camera through time/space ('cause space/time is overused) -- but they seem to have a two film system which can either freeze location (to one of a few predetermined spots) or freeze time at one instant. After time has been frozen once, you then need to wind that film through ALL those cameras before it can be done again.
It seems that the NFL have developed a significantly better system. Theirs seems to allow unconstrained motion in time/space -- thus you could imagine a shot panning along during [slow] motion of the subject. IIRC, we never saw this in the matrix; there the motion was always completely frozen when the camera moved.
I believe that the technology popularised by the Matrix (and used before that in several commercials) is already patented. A brief search on google failed to confirm this, tho.
As for the erasing part, that is pretty cool, technically; they'd have to pretty much incorporate all the visual inputs into one 3d interpretation of the scene, and then recreate the scene from the desired viewpoint. I had no idea that 3d visual research was that far advanced. Or can anyone suggest a Q-n-D approach?
Johan
Well, in that case, why not just relocate the farm to somewhere cold and close to a power plant; you get airconditioning for free (open the window, eh?) and electricity is availible. If opening the window isn't an option, land should be cheap enough so that you can afford to space your servers out a bit.
and you can now stop leasing expensive california real estate.
That lameness filter truly does suck. It's kinda self-referential in that way.
I tried to suggest that slashcode be modified so that users with enought karma could override the lameness filter (at least for ASCII-art), but was given a polite shove back the way I came.
oh well.
things are getting better; no longer can sequences be blindly patented without knowing what they do (this was previously possible -- I have no idea what they were smoking when they dreamt that one up).
So now there actually is a little bit more discovery necessary than the straight output of a DNA sequencer. I kinda think that the exact location of the gene that turns on cancer would be a valid patent. So you patent the understanding of the funtion, not the genes themselves.
hrm.
a wee bit of an Iain M Banks fan, perchance?
I dunno that the feature size is that much of a killer. I think we can claw back the low-clock rate by massive integration.
There's a lot of inefficiency inherent in the modular assembly process exemplified by your run-of-the-mill laptop. The processor talks to memory over a small bus, the hard-drive knows little of what will be requested next...
This is all the case because traditional manufacuring needs to modularise in order to acheive high enough yeilds to be price-effective. Hence each component needs to be a fast as possible (thus the smaller feature size) to achieve acceptable performance.
If the entire logic circuit of the laptop could be printed in one go -- Extrelemely Large Scale Integrationed -- I'd imagine that we could compensate for the lower clock speed by exploiting paralellism and asycn clocking. Instead of printing only one CPU, print ten, each with their own memory. Give 'em a nice wide bus to communicate...
Of course, no-one said that designing or programming this beast would be easy.
http://absurdgallery.com/polytron.html
Ah.
Would that it were not the case, but I suspect that the video licences are royalty based. This would work fine if RedHat sold each copy of its product, but since any yahoo can download it off their website, that seems to be a real killer (road kill on the superhighway, to torture your analogy).
Maybe a third party could sell the player, but we all know how well payware fares in the linux comunity.
fair 'nuff. I've often conscidered getting a tape drive, but can ill afford the IDE slot (SCSI is not an option for economic reasons). What I should do is reshuffle my drives to make a smallish raid mirrored partition (is that raid-0?) for my important work and run something fun on the the rest of the drives.
Unfortunately, my sys admin skills are unexceptional. I can't even make NFS work after restoring my file server to RedHat 2.2.16 compliance. I need to free up a weekend to fix this, but it's ski season, and a man's got to have priorities.