It's openly malicious when the owner of the computer on the other end complains. Sure, not many will notice and complain -- but if complaining did something, a few would. Dealing with the user who got infected can be reactive rather than proactive, provided it happens in a timely manner. Most compromised machines spew so much garbage that they're bound to hit someone who will notice and care.
Oh, I'm well aware of how progress works and that other people might have a use for them. I was just pointing out that your post:
What you're looking for is "SATA Expander".
was inaccurate. I am not looking for any such thing. If I want more performance, I'll get more disks or faster disks, and I'll attach each one to its own port. I have extras.
Wow, both your numbers are wrong. SATA 2.0 has a theoretical transfer rate of 3Gb/s, not 3GB/s. It also uses an 8b/10b encoding, so 3.0Gb/s translates to 300MB/s. Data throughput will be less than that, thanks to control protocol overhead, though the overhead is very small.
Modern drives do seriously better than 25MB/s. Seriously, go look at benchmarks. Also, SSDs, which are a very real design influence on things like SATA, are already getting close to the 300MB/s mark.
Missing pulses isn't a big deal if you have an accurate clock. Phase locked loops can be tuned to handle lots of missing pulses very, very well. If you're not moving, or know exactly how you're moving, you know when the pulses arrive even if you don't actually look at them. If you're moving, and don't know precisely how, then and only then do you need to be actively counting pulses -- and unless you're accelerating by nontrivial fractions of c in between pulse arrival times, you can still miss lots of pulses before your error in predicted pulse arrival time grows terribly large. Somehow I doubt that will be a problem.
You don't need to know the pulsar locations that precisely -- it is sufficient to know the *difference* between the distances from the epoch to the pulsar and your spacecraft to the pulsar. To do that, you simply need to start at a known location and count pulses as you move.
It makes the problem more complicated, but it does not add error. You don't think the GPS satellites are stationary, do you? The source of error here is uncertainty in the measurements of those positions. And it actually isn't that bad -- start your spacecraft near Sol, with position well enough defined that you know which pulse you're receiving. (When observing, you can only see the relative phasing of the pulsars, unlike GPS satellites which transmit a time base.) Then you need to count pulses as you move. You then know that, relative to your starting point (or, equivalently, the epoch), you've seen X0 pulses from pulsar 0, X1 from pulsar 1, etc. Knowing how many pulses closer to each of the pulsars you are tells you how far you are from your starting point (in spacetime, not just space, obviously). The error bars get larger as you move enough to get parallax effects -- since from Earth we can only measure the distance to a pulsar with modest precision, and its velocity perpendicular to us with even less. If, however, you have a radio telescope that can resolve the position of the pulsar with good precision, you get to add a long baseline parallax measurement to correct for that. Add a timebase transmitter at Earth as well, and the errors basically disappear -- errors of a few nanoseconds should be readily available. And once you're far enough away from Sol to make that transmitter difficult (more than a few lightyears), you'll know the pulsar trajectories well enough it won't matter as much.
Then your stego channel detects an error thanks to its checksumming. And it retransmits. Much like TCP. In fact, your stego channel could just be another layer of TCP.
You send the masking data first, since the recipient is the one who controls *which* masking data they ask for a retransmit on. Then the sender retransmits the real data. If you send the real data first, you have to know which piece to ask to resend. That requires some sort of framing or similar protocol, which would make it easier to spot.
Freenet is an option that *might* meet your needs. Unfortunately, it won't work well unless you're willing to run a node a large fraction of the time (might be hard for a laptop). And that implies a nontrivial bandwidth and disk commitment.
Whether it's reliable enough is another matter. Data that isn't accessed at all will become unavailable after a week or three; shorter term than that, or for data that's accessed at least occasionally, reliability is quite good. Speed isn't exciting, but a few seconds (maybe 15-30 if you don't access at all, maybe a lot longer if it's almost but not quite completely gone) latency and a few kB/s should be plenty here.
On the plus side, it is Free, anonymous, and secure. Of course, all of Adeona switching to it might represent a rather larger load than it's ever seen before -- and would probably be disastrous if those nodes didn't have a decent uptime percentage.
If they have a valid warrant they dont have to ask for permission. So never, ever tell them they can come in. Always tell them they do not have your permission, even if you think they have a valid warrant. Do not surrender your rights.
True, but you don't really want to be seen as trying to prevent them from executing a valid warrant. You need to make it clear that you don't consent, but that beyond that you aren't preventing them from coming in. The phrasing I've seen suggested is "I do not consent to a search of my residence." (Or vehicle, person, bag, etc.) Keep repeating that, regardless of how they phrase the question. Just saying "No." is a bad idea -- they're likely to keep asking, and you don't want to reply "no" when they phrase it as "Do you mind if we come in?" By the tenth time they ask you might be frustrated enough not to be paying full attention to the phrasing. Add "Am I under arrest?" and "Am I free to go?" and you have almost everything you might need to say to an officer.
You know, some of us would be willing to have the display involve a lens as well as the actual display element. Then your eye could focus at a normal distance (2m or so, for example) and see the tiny display in-focus.
I think rights should scale up. I really don't see a problem with that.
Oh, I see, you seem to have drunk the kool-aid and accepted that corporations are people who have rights. That's where the fault lies in all your examples, not with any inductive scaling.
All that said... in this particular example, I do want my house on Google. Or, to be specific, I want other people's houses on Google -- many times I've made use of the Street View pictures to see what my destination will look like. And I can see other people wanting the same when I give them directions to my house. And I don't mind the pictures being up, and I certainly don't intend to take up a hypocritical position on the matter.
Several people have suggested this. It doesn't work. Sudden changes are distracting. The goal is to have your brain stop treating the sensation as a vibration, so you don't notice that aspect any more, and treat it like a new sense. It really does operate like a new sense, btw -- you simply know which way is North. Your brain is not built to handle pulsed senses, so it won't treat pulsed input properly.
Because intermittent sensations are more distracting than continuous ones, and harder for your brain to tune out. Also, make the interval too long, and you can turn a fair amount without getting an update, which doesn't help your internal mapmaking. This is the same reason you want analog output rather than individual motors that are either on or off.
surface mount components on a custom PCB, to reduce size
Or an iPhone app plus an armband connected by a wire or bluetooth. There's a million dollar idea for you.
Why? The iPhone doesn't have the sensors you need, and even if it did, you don't want the output changing as you move your phone. Besides, the components required to do Bluetooth are as complicated as the components needed to do the entire thing self-contained.
A proper version of the belt (surface mount components on a custom PCB, to reduce size) would be fairly inconspicuous. The batteries are the bulkiest component at that point, and even those aren't too large. The motors could be attached to a normal leather belt, and the remainder would be about the same size as a cell phone or pager, and comparably inconspicuous.
Reduced power would be a big improvement (lighter batteries and longer runtime would both be good). Do you have a suggested part for the piezo units?
I'll look into piezos. I've been meaning to build an updated version for a while now. Also, they *do* need to run constantly. How would it know when to run and when not to? With it constantly on, your brain tunes it out at a conscious level and you stop noticing it, but you still know what direction North is. Having it turn on or off would be distracting.
In addition to the usual five, I can easily come up with acceleration / balance, proprioception, and temperature (though I suppose you could count that with touch). I suppose you could count time as well. What else did you list as distinct senses?
The long wavelength would make it tricky. What it would look like would depend on how you rendered them, I suppose. The real problem is the diffraction limit -- without a really large sensor, you can't get a very useful resolution. Remember, your eyes have an aperture (pupil) size about 10,000 times larger than the wavelengths of interest. So any vision based on wavelengths in the centimeter range (2.4 GHz wireless is 125mm, compared to 550nm for green light) will be *really* blurry unless you're carrying a gigantic antenna array.
Slashdot Mirror
It's openly malicious when the owner of the computer on the other end complains. Sure, not many will notice and complain -- but if complaining did something, a few would. Dealing with the user who got infected can be reactive rather than proactive, provided it happens in a timely manner. Most compromised machines spew so much garbage that they're bound to hit someone who will notice and care.
Oh, I'm well aware of how progress works and that other people might have a use for them. I was just pointing out that your post:
What you're looking for is "SATA Expander".
was inaccurate. I am not looking for any such thing. If I want more performance, I'll get more disks or faster disks, and I'll attach each one to its own port. I have extras.
Nope, none of those apply to me.
Huh? Why would I want to do that when I can just plug each drive into its own port?
Wow, both your numbers are wrong. SATA 2.0 has a theoretical transfer rate of 3Gb/s, not 3GB/s. It also uses an 8b/10b encoding, so 3.0Gb/s translates to 300MB/s. Data throughput will be less than that, thanks to control protocol overhead, though the overhead is very small.
Modern drives do seriously better than 25MB/s. Seriously, go look at benchmarks. Also, SSDs, which are a very real design influence on things like SATA, are already getting close to the 300MB/s mark.
The answer to that is better insulation. It will help in the summer as well.
Missing pulses isn't a big deal if you have an accurate clock. Phase locked loops can be tuned to handle lots of missing pulses very, very well. If you're not moving, or know exactly how you're moving, you know when the pulses arrive even if you don't actually look at them. If you're moving, and don't know precisely how, then and only then do you need to be actively counting pulses -- and unless you're accelerating by nontrivial fractions of c in between pulse arrival times, you can still miss lots of pulses before your error in predicted pulse arrival time grows terribly large. Somehow I doubt that will be a problem.
You don't need to know the pulsar locations that precisely -- it is sufficient to know the *difference* between the distances from the epoch to the pulsar and your spacecraft to the pulsar. To do that, you simply need to start at a known location and count pulses as you move.
It makes the problem more complicated, but it does not add error. You don't think the GPS satellites are stationary, do you? The source of error here is uncertainty in the measurements of those positions. And it actually isn't that bad -- start your spacecraft near Sol, with position well enough defined that you know which pulse you're receiving. (When observing, you can only see the relative phasing of the pulsars, unlike GPS satellites which transmit a time base.) Then you need to count pulses as you move. You then know that, relative to your starting point (or, equivalently, the epoch), you've seen X0 pulses from pulsar 0, X1 from pulsar 1, etc. Knowing how many pulses closer to each of the pulsars you are tells you how far you are from your starting point (in spacetime, not just space, obviously). The error bars get larger as you move enough to get parallax effects -- since from Earth we can only measure the distance to a pulsar with modest precision, and its velocity perpendicular to us with even less. If, however, you have a radio telescope that can resolve the position of the pulsar with good precision, you get to add a long baseline parallax measurement to correct for that. Add a timebase transmitter at Earth as well, and the errors basically disappear -- errors of a few nanoseconds should be readily available. And once you're far enough away from Sol to make that transmitter difficult (more than a few lightyears), you'll know the pulsar trajectories well enough it won't matter as much.
Then your stego channel detects an error thanks to its checksumming. And it retransmits. Much like TCP. In fact, your stego channel could just be another layer of TCP.
You send the masking data first, since the recipient is the one who controls *which* masking data they ask for a retransmit on. Then the sender retransmits the real data. If you send the real data first, you have to know which piece to ask to resend. That requires some sort of framing or similar protocol, which would make it easier to spot.
Freenet is an option that *might* meet your needs. Unfortunately, it won't work well unless you're willing to run a node a large fraction of the time (might be hard for a laptop). And that implies a nontrivial bandwidth and disk commitment.
Whether it's reliable enough is another matter. Data that isn't accessed at all will become unavailable after a week or three; shorter term than that, or for data that's accessed at least occasionally, reliability is quite good. Speed isn't exciting, but a few seconds (maybe 15-30 if you don't access at all, maybe a lot longer if it's almost but not quite completely gone) latency and a few kB/s should be plenty here.
On the plus side, it is Free, anonymous, and secure. Of course, all of Adeona switching to it might represent a rather larger load than it's ever seen before -- and would probably be disastrous if those nodes didn't have a decent uptime percentage.
If they have a valid warrant they dont have to ask for permission. So never, ever tell them they can come in. Always tell them they do not have your permission, even if you think they have a valid warrant. Do not surrender your rights.
True, but you don't really want to be seen as trying to prevent them from executing a valid warrant. You need to make it clear that you don't consent, but that beyond that you aren't preventing them from coming in. The phrasing I've seen suggested is "I do not consent to a search of my residence." (Or vehicle, person, bag, etc.) Keep repeating that, regardless of how they phrase the question. Just saying "No." is a bad idea -- they're likely to keep asking, and you don't want to reply "no" when they phrase it as "Do you mind if we come in?" By the tenth time they ask you might be frustrated enough not to be paying full attention to the phrasing. Add "Am I under arrest?" and "Am I free to go?" and you have almost everything you might need to say to an officer.
You know, I've looked and looked, but there simply isn't a nuclear accelerator licensing agency listed in the yellow pages.
News flash: most of the overhead images are aerial photos, not satellite, at least in cities.
And the street view stuff certainly isn't satellite, and you might just get lucky.
You know, some of us would be willing to have the display involve a lens as well as the actual display element. Then your eye could focus at a normal distance (2m or so, for example) and see the tiny display in-focus.
I think rights should scale up. I really don't see a problem with that.
Oh, I see, you seem to have drunk the kool-aid and accepted that corporations are people who have rights. That's where the fault lies in all your examples, not with any inductive scaling.
All that said... in this particular example, I do want my house on Google. Or, to be specific, I want other people's houses on Google -- many times I've made use of the Street View pictures to see what my destination will look like. And I can see other people wanting the same when I give them directions to my house. And I don't mind the pictures being up, and I certainly don't intend to take up a hypocritical position on the matter.
Several people have suggested this. It doesn't work. Sudden changes are distracting. The goal is to have your brain stop treating the sensation as a vibration, so you don't notice that aspect any more, and treat it like a new sense. It really does operate like a new sense, btw -- you simply know which way is North. Your brain is not built to handle pulsed senses, so it won't treat pulsed input properly.
Because intermittent sensations are more distracting than continuous ones, and harder for your brain to tune out. Also, make the interval too long, and you can turn a fair amount without getting an update, which doesn't help your internal mapmaking. This is the same reason you want analog output rather than individual motors that are either on or off.
Or an iPhone app plus an armband connected by a wire or bluetooth. There's a million dollar idea for you.
Why? The iPhone doesn't have the sensors you need, and even if it did, you don't want the output changing as you move your phone. Besides, the components required to do Bluetooth are as complicated as the components needed to do the entire thing self-contained.
Also, they *do* need to run constantly. How would it know when to run and when not to?
No, I mean, it can just send short pulses every second or so.
That's far more distracting than continuous.
Having it turn on or off would be distracting.
Having it at all would be distracting, until you got used to it.
Getting used to it takes a few hours. Then you don't really notice it unless you pay attention to it specifically.
A proper version of the belt (surface mount components on a custom PCB, to reduce size) would be fairly inconspicuous. The batteries are the bulkiest component at that point, and even those aren't too large. The motors could be attached to a normal leather belt, and the remainder would be about the same size as a cell phone or pager, and comparably inconspicuous.
Reduced power would be a big improvement (lighter batteries and longer runtime would both be good). Do you have a suggested part for the piezo units?
I'll look into piezos. I've been meaning to build an updated version for a while now. Also, they *do* need to run constantly. How would it know when to run and when not to? With it constantly on, your brain tunes it out at a conscious level and you stop noticing it, but you still know what direction North is. Having it turn on or off would be distracting.
In addition to the usual five, I can easily come up with acceleration / balance, proprioception, and temperature (though I suppose you could count that with touch). I suppose you could count time as well. What else did you list as distinct senses?
The long wavelength would make it tricky. What it would look like would depend on how you rendered them, I suppose. The real problem is the diffraction limit -- without a really large sensor, you can't get a very useful resolution. Remember, your eyes have an aperture (pupil) size about 10,000 times larger than the wavelengths of interest. So any vision based on wavelengths in the centimeter range (2.4 GHz wireless is 125mm, compared to 550nm for green light) will be *really* blurry unless you're carrying a gigantic antenna array.