Still, in Linux it just gives you an error message, or does what you would expect. I'm still curious about the origins of this bug, and where it is. I would look at the 'mv' command code first.
Except that string comparisons aren't particularly useful in deciding that two directory arguments are the same. You have to stat them and compare inodes and devs.
Yes, I know this is trying to be funny, but on/. accuracy counts in humor as well.
It could be several bugs, but it isn't clear. Does the same thing happen if you aren't moving the directory to itself as in the example?
mkdir x y
mv x y
Should leave you with subdir y containing subdir x, but 'mv x x' is an error. If the code for mv actually tries to treat 'mv x x' like 'mv x y' (x and y are directories), then it will be badly breaking the rules for using link(2) and unlink(2).
Although it isn't a particularly deep bug, the fact that it panics makes it pretty nasty. What I would be curious about it how/where it was introduced. None of the code involved should be special to Apple in any way, so what happens on BSD (probably gives you an error, right?). Linux gives: "mv: cannot move `x' to a subdirectory of itself, `x/x'", and I'd be very surprised that BSD doesn't do the same, so how did it get broken.
I agree, I think wireless issues, and in particular the proposals for Open Spectrum and allowing more underlay is one of the top five issues that need tech enlightened legislation (or at least to prevent hostile legislation).
Some people are just stupid. Perl doesn't require any support unless you are trying to do something fancy, and even then it's pretty easy. Just download and go. Maybe fire up CPAN and get the additional modules you need. Perl is just rock solid.
Now, if you are talking about more niche projects, you have to make sure you have something real, and not something tossed together and abandoned, but you have the source so you can know that, and even fix things if necessary. Let's face facts, you are more or less on your own even with commercial products. They are not going to anylize your problems space and implement a solution (or if they do, it will cost $250/hr for custom programming). You're much more likely to actually get support from the community with an OSS project. If the niche is tiny or the product not widely used, support is going to be a problem whether it is commercial or OSS.
How hard can it be to make the tail come out the other side and put it in upside down?
OTOH, the feature I need is FM Out, so it can work with the marine Radio/CD player in the boat. Radio Shack has these as a separate device, which is Ok, but ideal would be an integrated very low power FM transmitter.
Exactly how does this work, slashdot wants to know. Do you lose part of the first track, and just how wide does the marking have to be? If I can read between the lines, the "crippling" involves munging the TOC data in some way? If it can't read this bogus data, I guess the player just starts playing tracks at the point it can read, thus treating it as a read error, and recovering the stream if it can. Is that about right?
Doesn't this also mean that you can still read off the disk as data (computer CD player), and ignore the bogus TOC data? Windows probably won't cooperate, but other OSs should, right?
So, what you are saying is that the original comment was just a troll. If you don't use and are not interested in using Linux, then why are you commenting.
Since there are a large number of problems that are essentially disk bound, this is probably more important than an equal improvement in CPU speed.
Low power is a big win. There are blade servers based on these chips too, and you can pack a lot more low power blades into a box without cooking everything. Wasn't there a story linked here a while back about how MIPS/Watt is a more important performance metric for huge server farms?
The number of humans that can outcode GCC is vanishingly small, and even smaller when you have to do keep track of all sorts of parallel dependencies and such. If I had to guess, I would say their problem is that they don't have the necessary capital to do the software development they would need to make this idea really fly. This seems like more of a research project than a business plan, maybe if they enlisted more support from the community by openning things up GPL style, it might have a chance.
If you are going to make chips, you should concentrate your investment on designing and making the chips, not the software. I'm sure they could do another design cycle in more modern fab technology and get much more speed (or lower power if that is the priority).
Also, my impression is that they aren't sharing a lot of board level IP either. There are lots of applications that are getting StrongArm and other low power processors that would be an ideal market for them, but these are all small companies without a lot of bucks to risk with new designs. OTOH, if you give them a basic design that uses your chips, and sell cheap prototyping parts and support gear, your going to get a lot more inquiries. Would this be enough to turn it around for them? I don't know, but would you bet your company on Billy G. deciding to endorse tablets? Even if they are successful, the danger is that Intel can swoop in and steal the market. You're much better off staying small and concentrating on the emerging niches. Specifically, the embedded market where Linux is already a good fit and doing well.
Too bad, though, it was a good idea, but the timing was bad. They still have some investment money that hasn't been spent, but it would be difficult to change direction now.
Why would they need suits if it's all some Hollywood hoax? Building a big enough vacuum chamber would be harder than actually going to space, so why would they need protection from it?
It's right there in the Bill of Rights. The right to be secure in your person, papers and properties against unwarrented searches and sesures (paraphrasing, of course). The free speach aspect is secondary, although important as well.
Yes, the library is a public place, but what I look at and what I check out is my private business, and unless I'm already under investigation, they have no right to this information. My email is as private as normal letters, phone conversations and even my private conversations with a librarian about my library searches. This practice needs to be tested in court, and it surely will not stand.
The FBI has consistently shown themselves to be tools of buearocrats and the current administration, and they must be held to a higher standard. They don't need this to fight terrorism, they need to work with other government agencies and quit being so damned arrogant.
Yes, it is. The only way some really good transportation system can replace cars is if it fills all the needs addressed by cars, trucks and everything that drives down the road. The point is that the current system is very, very flexible, and once you have a car, the incremental cost of using it is relatively small. An advanced tube transport system could address all of the uses, but it probably won't, at least not in transition.
I love riding my bike, but it has some serious limitations. I have commuted over 20 miles each way at times, but that is about the practical distance limit for that mode, and I need a backup plan when it rains, snows or gets too cold. For my wife, it doesn't work at all, and even for me, taking my kids along doesn't work unless I have a very safe route (I have both a single and double trailer for them, but I'm not willing to risk an accident in traffic with them in the trailer).
Actually, I do bicycle communte whenever I can. For bad weather, I even have a folding bike that I can take on the trains (I'm too far from the trains to walk easily. As I stated, the problem is that public transport just doesn't cut it for many situations. I gave a couple of examples, and I could go on. The point is that public transport doesn't work well for many situations, even if the routes and frequency were good enough. Nobody is really trying to solve the right design problem, what we have isn't nearly flexible enough for all the uses people have for personal vehicles.
I live in a small part of NYC (Staten Island) and even here there are buses that run 24/7. A bus usually comes every half hour all day.
And you're trying to defend Mass transit this way? Waiting even 10 minutes for a bus/train when it's below zero just isn't acceptable for most people, and it can be dangerous for young kids and elderly as well. OTOH, 24 hours a day, there is enough car traffic on streets and highways to justify a bus or train every few minutes, so if everyone was out of there car and on the busses and trains, it might be workable.
They usually have $15 metrocards, they work on buses and trains, when you get on the bus you just stick the card in the slot and get on, very quick and very easy.
I don't know about your metrocard system, but they introduced faircards on the CTA a couple of years ago, and in typical buearocracy fashion, it rips off the consumer in a number of sublte ways. First, there is no way to take fractions of a fair from several cards onto one, and not even a way to get a newly issued card from the fraction and additional cash. The cards expire in a year, so if you just keep adding 10 bucks to your card you might find it has expired with 8.80 still on it. There is no way to get change or refund from a card, and change machines in the stations are often empty or malfunctioning.
The other thing about mass transit, is that it doesn't handle all of your trasportation needs. Try hauling 100+ pounds of groceries and other products home from the store on the bus. Sure, you can do it if you are strong, and have a cart or something, but every time you change from one route to another you have to get it on/off and lug it some distance. That's only one example, but it is one that effects almost everyone, and the really impossible uses are often more specific. I own a sailboat, which requires maintanace every spring, and there is no way I could get to and from the boatyard with a trunkload of tools and supplies without a car. Almost everyone has some special use like this that is not handled. Don't get me started about how hard it is to bring a bike on the train, even though they have started to allow for this (some CTA busses even have bike racks on the front now, but still this handles only one of two bikes per bus, if it is filled, your out of luck).
That's one of the big problems with this evactuated tube thing as well. Whatever the tube size it (and it looks quite small int he proposal drawings), it is an absolute limit. The only absolute limit on the interstates is '14 minimum clearance on all overpasses (there is a width too, but it's wide enough to not come into play). Yes you need special permits for oversize, but with the tubes, there is no flexibility.
I've had this idea of a while that you could "tile" a large flat screen monitor from standard low res flat panels. With existing tech, you could do way better than this project by finding the cheapest low res LCD monitors, and either find a model with narrow edge trim, or remount the screens to get minimal spacing. Of course, this is lame if the screens aren't cheap enough, and who really wants a big screen with visible lines between tiles. What I wonder is, whether it is possible to design a module and mounting method that eliminates the lines completely. Maybe have modules that butt right up to each other (maybe even connect together, but I digress), and then have a single piece glass in front, possibly with a difusion surface to help merge the pixels. For big screens, even with high res, the actual pixels could be pretty big, so you could have 1'x1' module with say a 20 dot per inch pitch for 240x240 pixels.
Ok, maybe twice that resolution for an HDTV resolution in smaller sizes, but this would be good for say on 8x12 screen. They would have to be $10-50 per tile to be really worthwhile, but even a bit more than this would be competetive with current large flat panels, but you need to get down to the lower end of this to make it really popular. The big if would be whether it looks just as good as a one-piece design.
Well, aside from budget considerations, I'm on a 'home' class DSL which makes even my in-house wired NAT box slightly grey, and I don't really want to push any legalities. I like that some people are pushing the envelope in these areas, but I want to stay within the lines on this.
The right way to do this is with bandwidth cooperatives. You just need a couple of wired points in your mesh where you are licensed to share upstream bandwidth, then you can expand outward from those points. I can think of a number of interesting business plans to develop networks like this, and I might consider some of them in the context of an educational initiative I'm trying to get off the ground. OTOH, if someone else gets there first, I'd be perfectly happy to drop a few hundred and mount one of these boxes in my attic.
It would have been even more useful in the first year or so of my DSL service when it was a bit unreliable. I'm sure that I would want to keep my DSL service in the near term until I have some confidence in the reliability of the mesh network. It sure would be nice if this kind of configuration was fully supported by the AP so that mesh traffic stays on the mesh, and both authorized wireless and wired nodes could be routed either through the mesh or a wired ISP connection.
When I followed the link to "community mesh network", there were hardware and software links to the site, so I assume you can just get the software to set up your node. Of course this doesn't get interesting unless you have a handful of mesh node to connect with and create an extended network.
Star is correct for the typical WiFi network with one or more wired APs and many leaf nodes. These nodes will connect to one another for routing exclusively through a wireless "mesh" of nodes, hence the name. This is a superset of cell topo where you hook up to wired base stations in a star topo, but you can be handed off while moving. Cell type handoff should be part of this type of network as well, but it will probably be controlled in the "client" node rather than being a function of the network as will cell phones.
This is a very cool development, and I can't wait until a network develops in my neighborhood. I wonder how dense these things have to be to get good coverage in an urban environment?
There are a lot of very wrong answers in the comments here, and some good ones. I haven't messed with this in detail since the SCSI-I days, but the spec was designed to support this from the very beginning. On the other hand, this configuration is pretty rare, so not all drives and host adapters are going to handle it properly (test the devices you want to use).
As someone else said, you want to look at "multi-initiator" support. Since there's not much point to using SCSI if you can't interleave requests, your going to be talking about "split transactions" where the initiator arbitrates for the bus, selects a target and sends a command and possibly data (write case) over the bus and then disconnects. Later, the target arbitrates for the bus, selects the initiator (hopefully the same one that sent the request), and sends data (read case) and status back. IIRC, SCSI-I didn't support tagged queing and out of order returns, but later versions do. This has got to be negotiated just like synchronous transfer rate. I can think of lots of ways that this could be screwed up (typically in firmware) and never effect the single initiator case, so as I said, you have to test.
If the drive fully and correctly supports the spec, it should respond correctly to requests from any initiator and keep everything straight when it agrees to handle tagged queing. That means you should be able to use different parts of the disk for a filesystem on each disk, as long as you keep everything straight. You can even have one device write and another read, or use some blocks on the disk to coordinate dynamic sharing, but all of that gets complicated quickly, so unless this is what you really want, it won't be worth it.
A couple of comments implied that some music systems do this sort of thing, maybe between the sound recording system and a computer mixer/processor system. Doing this can't break the drive, but it certainly could hose up the format enough to make it unusable without a reformat (if you break the usage rules, that is).
As to cables and such, SCSI is a bus, although you are allowed short taps from the bus to the drives/controlers (maximum is in the spec). If you have some sort of 'Y' cable that connects a host in two directions, you can't have more than one device inside the host (i.e. no drives inside the case connected to the internal port of the controller), and the internal cable has to be short enough (and of course no termination inside either). External drives and multi-drive modules will almost always have two connections for both ends of the bus, so just chain all the drives together and put the hosts on each end. Now you just have to be sure the total cable lenght is within spec (6 meters, I think).
The final topic is why do it in the first place. Keep in mind that drives and power supplies are your most likely failure points in any case, so you want to mirror, or raid. Mirroring with one drive in each box (or many pairs split between the boxes) would reduce the single points of failure pretty well. You could even have both boxes active and mirroring to different pairs sharing the load until there is a failure, then switch over. Manual switch over is probably safest and cheapest, just shutdown the broken system (If not already hard crashed), and mount the other filesystems on the still working box. If you have confidence in your monitoring system, you could script this on certain events.
It looked like some comments had good links to some multi-initiator stuff, or just google that as suggested (it helps when you know what to ask for), YMMV. Oh, one more thing to worry about: terminator power. Usually the controller supplies it to the bus, but it is very bad for more than one device or initiator to supply it. Of course, you also have to worry about still having it at both ends even if one of the machines is off or dead.
Is there any public information about what the documents contain? There must be at least some general information related to the original dispute and the arguments about whether they could be kept private (obviously Caldera won this point since they have the documents). Presumably these are copies if MS needed to keep the orgininals for themselves, although by now those may be gone.
Can they be released to a third party for preservation? Even if they can't be released, someone could pay to preserve them if there would be any future value in that. I can understand Caldera not being interested in paying to keep them.
Given the powers at which these lasers operate, I imagine that the mirror would be effective shielding for a few tenths of a second before the energy not reflected built up enough to scorch the silvering. Once that happens you're dead.
If mirrors just don't work, then do you have to point the whole laser assembly? On a ship or tank, you might be able to direct a turret to the target, but that means targeting wouldn't be as fast as you would like. For an aircraft, you're probably going to have to turn to the target, which might make it kind of difficult to hit an incoming rocket.
You could look at longer term constraints like meeting payroll as a real-time constraint, but you're right, the deadlines are not really hard. Typically this type of processing falls into the 'batch' processing category which has some interesting parallels to real-time, but with a much longer time-scale. There is very little true batch processing any more, but it used to be the dominant model for most business data processing.
Whenever you have to control a high speed process, you need real-time. No, it doesn't mean 'live', but instead it relates to situations where you have hard timing limits that you have to meat for things to even work. Single session CD-writing is a good example, if your application/OS combo doesn't meat the hard real-time deadlines related to how fast the physical disc is spinning, you've just wasted the media blank and have to start over. In many real-time applications, not meeting the timing can mean the equipment may be dammaged or destroyed, possibly in a manner dangerous to anyone standing around operating it. A lot of times it is more an issue of quality suffering, so real-time is more of a desirable target than an absolute necessity.
Slashdot Mirror
Still, in Linux it just gives you an error message, or does what you would expect. I'm still curious about the origins of this bug, and where it is. I would look at the 'mv' command code first.
Yes, I know this is trying to be funny, but on /. accuracy counts in humor as well.
Should leave you with subdir y containing subdir x, but 'mv x x' is an error. If the code for mv actually tries to treat 'mv x x' like 'mv x y' (x and y are directories), then it will be badly breaking the rules for using link(2) and unlink(2).
Although it isn't a particularly deep bug, the fact that it panics makes it pretty nasty. What I would be curious about it how/where it was introduced. None of the code involved should be special to Apple in any way, so what happens on BSD (probably gives you an error, right?). Linux gives: "mv: cannot move `x' to a subdirectory of itself, `x/x'", and I'd be very surprised that BSD doesn't do the same, so how did it get broken.
I agree, I think wireless issues, and in particular the proposals for Open Spectrum and allowing more underlay is one of the top five issues that need tech enlightened legislation (or at least to prevent hostile legislation).
Now, if you are talking about more niche projects, you have to make sure you have something real, and not something tossed together and abandoned, but you have the source so you can know that, and even fix things if necessary. Let's face facts, you are more or less on your own even with commercial products. They are not going to anylize your problems space and implement a solution (or if they do, it will cost $250/hr for custom programming). You're much more likely to actually get support from the community with an OSS project. If the niche is tiny or the product not widely used, support is going to be a problem whether it is commercial or OSS.
OTOH, the feature I need is FM Out, so it can work with the marine Radio/CD player in the boat. Radio Shack has these as a separate device, which is Ok, but ideal would be an integrated very low power FM transmitter.
Exactly how does this work, slashdot wants to know. Do you lose part of the first track, and just how wide does the marking have to be? If I can read between the lines, the "crippling" involves munging the TOC data in some way? If it can't read this bogus data, I guess the player just starts playing tracks at the point it can read, thus treating it as a read error, and recovering the stream if it can. Is that about right?
Doesn't this also mean that you can still read off the disk as data (computer CD player), and ignore the bogus TOC data? Windows probably won't cooperate, but other OSs should, right?
Since there are a large number of problems that are essentially disk bound, this is probably more important than an equal improvement in CPU speed.
The number of humans that can outcode GCC is vanishingly small, and even smaller when you have to do keep track of all sorts of parallel dependencies and such. If I had to guess, I would say their problem is that they don't have the necessary capital to do the software development they would need to make this idea really fly. This seems like more of a research project than a business plan, maybe if they enlisted more support from the community by openning things up GPL style, it might have a chance.
If you are going to make chips, you should concentrate your investment on designing and making the chips, not the software. I'm sure they could do another design cycle in more modern fab technology and get much more speed (or lower power if that is the priority).
Also, my impression is that they aren't sharing a lot of board level IP either. There are lots of applications that are getting StrongArm and other low power processors that would be an ideal market for them, but these are all small companies without a lot of bucks to risk with new designs. OTOH, if you give them a basic design that uses your chips, and sell cheap prototyping parts and support gear, your going to get a lot more inquiries. Would this be enough to turn it around for them? I don't know, but would you bet your company on Billy G. deciding to endorse tablets? Even if they are successful, the danger is that Intel can swoop in and steal the market. You're much better off staying small and concentrating on the emerging niches. Specifically, the embedded market where Linux is already a good fit and doing well.
Too bad, though, it was a good idea, but the timing was bad. They still have some investment money that hasn't been spent, but it would be difficult to change direction now.
Why would they need suits if it's all some Hollywood hoax? Building a big enough vacuum chamber would be harder than actually going to space, so why would they need protection from it?
Yes, the library is a public place, but what I look at and what I check out is my private business, and unless I'm already under investigation, they have no right to this information. My email is as private as normal letters, phone conversations and even my private conversations with a librarian about my library searches. This practice needs to be tested in court, and it surely will not stand.
The FBI has consistently shown themselves to be tools of buearocrats and the current administration, and they must be held to a higher standard. They don't need this to fight terrorism, they need to work with other government agencies and quit being so damned arrogant.
I love riding my bike, but it has some serious limitations. I have commuted over 20 miles each way at times, but that is about the practical distance limit for that mode, and I need a backup plan when it rains, snows or gets too cold. For my wife, it doesn't work at all, and even for me, taking my kids along doesn't work unless I have a very safe route (I have both a single and double trailer for them, but I'm not willing to risk an accident in traffic with them in the trailer).
Actually, I do bicycle communte whenever I can. For bad weather, I even have a folding bike that I can take on the trains (I'm too far from the trains to walk easily. As I stated, the problem is that public transport just doesn't cut it for many situations. I gave a couple of examples, and I could go on. The point is that public transport doesn't work well for many situations, even if the routes and frequency were good enough. Nobody is really trying to solve the right design problem, what we have isn't nearly flexible enough for all the uses people have for personal vehicles.
And you're trying to defend Mass transit this way? Waiting even 10 minutes for a bus/train when it's below zero just isn't acceptable for most people, and it can be dangerous for young kids and elderly as well. OTOH, 24 hours a day, there is enough car traffic on streets and highways to justify a bus or train every few minutes, so if everyone was out of there car and on the busses and trains, it might be workable.
They usually have $15 metrocards, they work on buses and trains, when you get on the bus you just stick the card in the slot and get on, very quick and very easy.
I don't know about your metrocard system, but they introduced faircards on the CTA a couple of years ago, and in typical buearocracy fashion, it rips off the consumer in a number of sublte ways. First, there is no way to take fractions of a fair from several cards onto one, and not even a way to get a newly issued card from the fraction and additional cash. The cards expire in a year, so if you just keep adding 10 bucks to your card you might find it has expired with 8.80 still on it. There is no way to get change or refund from a card, and change machines in the stations are often empty or malfunctioning.
The other thing about mass transit, is that it doesn't handle all of your trasportation needs. Try hauling 100+ pounds of groceries and other products home from the store on the bus. Sure, you can do it if you are strong, and have a cart or something, but every time you change from one route to another you have to get it on/off and lug it some distance. That's only one example, but it is one that effects almost everyone, and the really impossible uses are often more specific. I own a sailboat, which requires maintanace every spring, and there is no way I could get to and from the boatyard with a trunkload of tools and supplies without a car. Almost everyone has some special use like this that is not handled. Don't get me started about how hard it is to bring a bike on the train, even though they have started to allow for this (some CTA busses even have bike racks on the front now, but still this handles only one of two bikes per bus, if it is filled, your out of luck).
That's one of the big problems with this evactuated tube thing as well. Whatever the tube size it (and it looks quite small int he proposal drawings), it is an absolute limit. The only absolute limit on the interstates is '14 minimum clearance on all overpasses (there is a width too, but it's wide enough to not come into play). Yes you need special permits for oversize, but with the tubes, there is no flexibility.
Ok, maybe twice that resolution for an HDTV resolution in smaller sizes, but this would be good for say on 8x12 screen. They would have to be $10-50 per tile to be really worthwhile, but even a bit more than this would be competetive with current large flat panels, but you need to get down to the lower end of this to make it really popular. The big if would be whether it looks just as good as a one-piece design.
The right way to do this is with bandwidth cooperatives. You just need a couple of wired points in your mesh where you are licensed to share upstream bandwidth, then you can expand outward from those points. I can think of a number of interesting business plans to develop networks like this, and I might consider some of them in the context of an educational initiative I'm trying to get off the ground. OTOH, if someone else gets there first, I'd be perfectly happy to drop a few hundred and mount one of these boxes in my attic.
It would have been even more useful in the first year or so of my DSL service when it was a bit unreliable. I'm sure that I would want to keep my DSL service in the near term until I have some confidence in the reliability of the mesh network. It sure would be nice if this kind of configuration was fully supported by the AP so that mesh traffic stays on the mesh, and both authorized wireless and wired nodes could be routed either through the mesh or a wired ISP connection.
When I followed the link to "community mesh network", there were hardware and software links to the site, so I assume you can just get the software to set up your node. Of course this doesn't get interesting unless you have a handful of mesh node to connect with and create an extended network.
This is a very cool development, and I can't wait until a network develops in my neighborhood. I wonder how dense these things have to be to get good coverage in an urban environment?
As someone else said, you want to look at "multi-initiator" support. Since there's not much point to using SCSI if you can't interleave requests, your going to be talking about "split transactions" where the initiator arbitrates for the bus, selects a target and sends a command and possibly data (write case) over the bus and then disconnects. Later, the target arbitrates for the bus, selects the initiator (hopefully the same one that sent the request), and sends data (read case) and status back. IIRC, SCSI-I didn't support tagged queing and out of order returns, but later versions do. This has got to be negotiated just like synchronous transfer rate. I can think of lots of ways that this could be screwed up (typically in firmware) and never effect the single initiator case, so as I said, you have to test.
If the drive fully and correctly supports the spec, it should respond correctly to requests from any initiator and keep everything straight when it agrees to handle tagged queing. That means you should be able to use different parts of the disk for a filesystem on each disk, as long as you keep everything straight. You can even have one device write and another read, or use some blocks on the disk to coordinate dynamic sharing, but all of that gets complicated quickly, so unless this is what you really want, it won't be worth it.
A couple of comments implied that some music systems do this sort of thing, maybe between the sound recording system and a computer mixer/processor system. Doing this can't break the drive, but it certainly could hose up the format enough to make it unusable without a reformat (if you break the usage rules, that is).
As to cables and such, SCSI is a bus, although you are allowed short taps from the bus to the drives/controlers (maximum is in the spec). If you have some sort of 'Y' cable that connects a host in two directions, you can't have more than one device inside the host (i.e. no drives inside the case connected to the internal port of the controller), and the internal cable has to be short enough (and of course no termination inside either). External drives and multi-drive modules will almost always have two connections for both ends of the bus, so just chain all the drives together and put the hosts on each end. Now you just have to be sure the total cable lenght is within spec (6 meters, I think).
The final topic is why do it in the first place. Keep in mind that drives and power supplies are your most likely failure points in any case, so you want to mirror, or raid. Mirroring with one drive in each box (or many pairs split between the boxes) would reduce the single points of failure pretty well. You could even have both boxes active and mirroring to different pairs sharing the load until there is a failure, then switch over. Manual switch over is probably safest and cheapest, just shutdown the broken system (If not already hard crashed), and mount the other filesystems on the still working box. If you have confidence in your monitoring system, you could script this on certain events.
It looked like some comments had good links to some multi-initiator stuff, or just google that as suggested (it helps when you know what to ask for), YMMV. Oh, one more thing to worry about: terminator power. Usually the controller supplies it to the bus, but it is very bad for more than one device or initiator to supply it. Of course, you also have to worry about still having it at both ends even if one of the machines is off or dead.
Can they be released to a third party for preservation? Even if they can't be released, someone could pay to preserve them if there would be any future value in that. I can understand Caldera not being interested in paying to keep them.
If mirrors just don't work, then do you have to point the whole laser assembly? On a ship or tank, you might be able to direct a turret to the target, but that means targeting wouldn't be as fast as you would like. For an aircraft, you're probably going to have to turn to the target, which might make it kind of difficult to hit an incoming rocket.
You could look at longer term constraints like meeting payroll as a real-time constraint, but you're right, the deadlines are not really hard. Typically this type of processing falls into the 'batch' processing category which has some interesting parallels to real-time, but with a much longer time-scale. There is very little true batch processing any more, but it used to be the dominant model for most business data processing.
Whenever you have to control a high speed process, you need real-time. No, it doesn't mean 'live', but instead it relates to situations where you have hard timing limits that you have to meat for things to even work. Single session CD-writing is a good example, if your application/OS combo doesn't meat the hard real-time deadlines related to how fast the physical disc is spinning, you've just wasted the media blank and have to start over. In many real-time applications, not meeting the timing can mean the equipment may be dammaged or destroyed, possibly in a manner dangerous to anyone standing around operating it. A lot of times it is more an issue of quality suffering, so real-time is more of a desirable target than an absolute necessity.
I wonder if using Windows or Apples effects your gate and if so, how.
Of course, they probably didn't survey anyone at the RIAA or MPAA, did they?