Let's see, LEDs 1/3 mm across. My pupil is about 5mm, so that gives me a resolution of about 15 pixels across. Not so good, especially considering that to get that 15 pixels I would have to block everything else!
The term of art you are looking for is "Offensive Nonmutual Collateral Estoppel." If the true owner is a member of RIAA, then it may be precluded from raising this issue in a new case. This is a complex doctrine, and based on what I remember, some of the elements may not be met here, but this is definately worth looking into.
You're kidding, right? You say that you are not being hyperbolic because you have dealt with people actually think and say things like this. Have you actually met anyone who said all of that? Perhaps there are some wackos out there that think like that, but I think that you will find that most Christian Fundamentalists have no problem with such research.
I cannot believe that this post got rated 4 Interesting! It is a troll and a screed. If you need any more evidence of this, just look at the last paragraph talking about Iraq. A true war for oil would have us occupying the oil fields and leaving the rest of the country to rot. It would not have us trying to establish democracy in Iraq and pumping in lots of money and then letting them sell the oil to anybody they want and keep the profits.
Frequently companies will structure people purchases as stock deals such as this one. Apple may care about the code, but what they really want is the programmer. By structuring the deal as a stock purchase, the programmer, who owned the company that was sold, only has to pay capital gains tax at 15% rather than income tax at 36%. He will have to pay income tax on the nominal amount they will pay him over the next several years as a programmer.
When I was working for a stock brokerage, we a had DU DecSafe failover setup. However, it had a drawback in that if something simple like a network card failed, it would still have to failover the whole system, which would take more than a few min because of the database. We decided that we wanted to have the running system failover to an alternative network card instead. We came up with a couple of simple programs that helped us out on that. First, we had a program that would set the MAC address on the card to whatever we fed as input. Second, we had a program that would poll the card for a failure once every half second or so. It would exit on failure. Third, we used a script at start-up that set both mac addresses to some values. Then we started the checking program. If this would cause a busy-wait condition. When the card failed, such as someone disconnecting it, the program would exit, and the rest of the script would run. The rest of the script 1 downed the bad card 2 changed it's MAC address to some third address 3 changed the backup card to the working address 4 upped the backup card with the systems IP address. 5 notified the operator We only changed the MAC address because we had some PCs that couldn't handle the change. If the system had been behind a rounter this wouldn't have been an issue. If you wanted to you could do some other things to make this setup even more useful, such as using the second card for heartbeat checking or whatnot. This was not difficult to write. Most of the work took 2 or 3 hours. A few days to add some nice details to the scripting, and we were off and running. Some things that can be added if you do it right: Allow the cards to fail back the other way if the first card comes back on-line Have a third card in the chain if you are really hyper about uptime just a thought -cliff (no, not that cliff, the other one)
I think the part that is most likely to keep this from happening is the raw material problem. Computer viri can easily replicate because the raw material, cpu cycles and memory, are so cheap and available (both are important) as to have almost 0 transaction cost. Not so with physical material needed to replicate a robot. (Damn, Coase would be proud).
Slashdot Mirror
Let's see, LEDs 1/3 mm across. My pupil is about 5mm, so that gives me a resolution of about 15 pixels across. Not so good, especially considering that to get that 15 pixels I would have to block everything else!
The term of art you are looking for is "Offensive Nonmutual Collateral Estoppel." If the true owner is a member of RIAA, then it may be precluded from raising this issue in a new case. This is a complex doctrine, and based on what I remember, some of the elements may not be met here, but this is definately worth looking into.
You're kidding, right? You say that you are not being hyperbolic because you have dealt with people actually think and say things like this. Have you actually met anyone who said all of that? Perhaps there are some wackos out there that think like that, but I think that you will find that most Christian Fundamentalists have no problem with such research.
I cannot believe that this post got rated 4 Interesting! It is a troll and a screed. If you need any more evidence of this, just look at the last paragraph talking about Iraq. A true war for oil would have us occupying the oil fields and leaving the rest of the country to rot. It would not have us trying to establish democracy in Iraq and pumping in lots of money and then letting them sell the oil to anybody they want and keep the profits.
Frequently companies will structure people purchases as stock deals such as this one. Apple may care about the code, but what they really want is the programmer. By structuring the deal as a stock purchase, the programmer, who owned the company that was sold, only has to pay capital gains tax at 15% rather than income tax at 36%. He will have to pay income tax on the nominal amount they will pay him over the next several years as a programmer.
When I was working for a stock brokerage, we a had DU DecSafe failover setup. However, it had a drawback in that if something simple like a network card failed, it would still have to failover the whole system, which would take more than a few min because of the database. We decided that we wanted to have the running system failover to an alternative network card instead. We came up with a couple of simple programs that helped us out on that. First, we had a program that would set the MAC address on the card to whatever we fed as input. Second, we had a program that would poll the card for a failure once every half second or so. It would exit on failure. Third, we used a script at start-up that set both mac addresses to some values. Then we started the checking program. If this would cause a busy-wait condition. When the card failed, such as someone disconnecting it, the program would exit, and the rest of the script would run. The rest of the script 1 downed the bad card 2 changed it's MAC address to some third address 3 changed the backup card to the working address 4 upped the backup card with the systems IP address. 5 notified the operator We only changed the MAC address because we had some PCs that couldn't handle the change. If the system had been behind a rounter this wouldn't have been an issue. If you wanted to you could do some other things to make this setup even more useful, such as using the second card for heartbeat checking or whatnot. This was not difficult to write. Most of the work took 2 or 3 hours. A few days to add some nice details to the scripting, and we were off and running. Some things that can be added if you do it right: Allow the cards to fail back the other way if the first card comes back on-line Have a third card in the chain if you are really hyper about uptime just a thought -cliff (no, not that cliff, the other one)
I think the part that is most likely to keep this from happening is the raw material problem. Computer viri can easily replicate because the raw material, cpu cycles and memory, are so cheap and available (both are important) as to have almost 0 transaction cost. Not so with physical material needed to replicate a robot. (Damn, Coase would be proud).