Devoting much of his 20-page ruling to how new technology delves into a person's life, Lippman said: "What the technology yields and records with breathtaking quality and quantity, is a highly detailed profile, not simply of where we go, but by easy inference, of our associations -- political, religious, amicable and amorous, to name only a few -- and of the pattern of our professional and avocational pursuits."
That same line of reasoning would apply not only to a GPS bug on your car, but also to someone following you around with a notepad.
Indeed, I don't think that quote in isolation presents the best case against warrantless GPS tracking, by far. I haven't seen the decision, so for all I know the quote is not representative.
Anyway, in mind this issue isn't about whether GPS tracking, applied to a given, individual case, can collect information that can't be collected by tailing the suspect. The issue is about the American tradition of restricting the power of the police, in order to protect the people from abuse by the authorities. Even if GPS tracking and following somebody around produce the same information, warrantless GPS tracking quite simply gives the police much more opportunity to abuse their power than their current ability to follow suspects.
Having a detective tail a suspect is costly, so the police can be expected to limit its use to the cases where they most expect to uncover evidence of a crime. Warrantless GPS tracking, on the other hand, is cheap, so the police will be tempted to abuse their power by tracking all sorts of people who did nothing wrong. They will undoubtedly uncover some folks' secrets, and there will always be the temptation to use those secrets against them ("tell me what you know about my suspect, and I won't tell your wife about your weekly visits to Motel 8 to see your mistress.").
If following somebody in an unmarked car without a warrant is legal (and it is), I'm not sure why an electronic device that accomplishes the same thing through satellite tracking would not be.
This issue isn't about whether GPS tracking, applied to one individual case, can collect information that can't be collected by tailing the suspect. The issue is about the restrictions on the power of the police to mess with people. Even if GPS tracking and following somebody around produce the same information, warrantless GPS tracking gives the police plenty more opportunity to abuse their power.
Having a detective tail a suspect is costly, so the police can be expected to limit its use to the cases where they most expect to uncover evidence of a crime. Warrantless GPS tracking, on the other hand, is cheap, so the police will be tempted to abuse their power by tracking all sorts of people who did nothing wrong.
This information is relevant because one of Apple's selling point for the iPhone is that it is a good software platform. If you're attracted to the iPhone because of this reason, Apple's restrictions on what software they allow the platform to run is a very important piece of information, whether you're interested on buying a phone or developing for it. This is the reason why this is important news: it's relevant to deciding whether to buy into the iPhone.
Quite frankly, I think that Apple's restrictiveness in this regard makes me absolutely unwilling to develop software for that platform; they just simply would have too much control over the software, like dictating to me the distribution terms, or cancelling it arbitrarily.
You're making the mistake that concurrency is the same thing as parallelism. It is not. Concurrency is when a program is written in such a way that the order of execution of tasks is highly underspecified; parallelism is the use of multiple execution units to execute concurrent code.
Concurrency isn't just for performance; concurrency is just as much for writing software that can do many things at once. For example, one needs concurrency to have client applications that respond to the user with very low latency while doing some other work in the background. In this case, in fact, the software isn't trying to perform its heavy computations in the absolute minimum time; it's OK to slow down the heavy computation somewhat in order to reduce user interface latency. Have you ever used one of those applications where the whole UI hangs (e.g., won't even draw) while the application does some action, like connecting to a server? That's a failure to provide concurrency.
Contrary to common wisom, the introduction of multicore processors didn't increase our need for good tools for concurrent programming, because we've needed such tools since way before for user interaction. The tools that conventional languages provide for threading and synchronization are too hard to use, leading programmers to introduce far less concurrency into the software than they otherwise could. Also, conventional threads are much too heavyweight for an application to create thousands of them.
One example, I submitted and update to an EBCDIC encoding used on IBM mainframes. The encoding had several choices for what should be encoded as the newline character. It wasn't clear which one should be used, but the z/OS system I was using had definitely chosen a particular one. Glibc had chosen a different one. I submitted a patch that changed it and Ulrich rejected it saying that there wasn't a standard and so my version was no more valid than the version that was in the library.
Um, if you're describing that right, isn't he right to reject your patch? What if I'm a user of another EBDDIC system, and that system uses the choice that's in the library? Does that mean that if your patch is accepted, my patch to undo yours should be equally accepted?
If it is obvious that the debtor will never be able to pay back, you would have trouble selling the loan, right? Unless the buyer is unaware of the risk involved, of course.
Exactly. Securitization packages up pools of loans into bonds that get given a credit rating by an agency. A lot of bond buyers just go by the bonds' ratings. These bond buyers are the ones who ultimately provide the easy money that ends up being used for the junk mortgages.
Who are these bond buyers? All sorts of banks, and, more worrisome, retirement pensions and bond mutual funds in people's 401k plans. Look, for example, at what happened to Fidelity Ultra-Short Bond Fund. This is a fund that was supposed to be extra-low risk; it lists "preservation of capital" as a goal, and it's supposed to compete with money-market funds and bank accounts. It lost 20% because of exposure to highly-rated subprime securities.
The article isn't seriously claiming that one guy was responsible for it, nor that it was due to a software bug. The article was written by a guy who developed some mortgage securitization software, who tells his story and idly asks himself to what extent he shares responsibility for the debacle.
Can you say scapegoat? Of course, it's a geek who is to blame for it all with his immoral software witchery. It couldn't possibly be the result of a large number of greedy, thieving scum, who were regulated by greedy, corrupt scum, and they in turn were regulated by a greedy, corrupt government.
Um, dude, RTFA. It's a piece by a software developer who wrote a bunch of software for mortgage securitization, telling his story and doing some navel-gazing about whether he should feel guilty about his part in the debacle.
IPv6 is depressing, because whoever is in charge of it does such a crummy job of explaining what it is and why I should care, and more importantly, why my folks should care.
Actually, I would claim that that's not a big deal. The big problem is that IPv6 just doesn't provide a sensible migration path from IPv4. The idea that we're all going to wake up one day and switch off IPv4 at once just doesn't cut it. More precisely, an IPv4 node just has no way of talking to an IPv6 node. If we built some sort of standardized IPv4-to-IPv6 NAT technology that was invisible to existing IPv4 nodes, then IPv6 could be adopted gradually and incrementally with minimal cost (the cost could be rolled into the cost of general network gear upgrades).
At this point we're just using hypotheses and another one that I just dreamed up is that ths strain needs a certain industrial polutants to be between certain points (sweet spot) for it to be lethal. Since more people have caught it, and more people have died from it in Mexico, this is also plausible, since the polution levels are easily higher there than in the US and Europe. I say plausible, but very unlikely, as I just came up with this halfassed idea. But if it ends up being true, I want credit!
If the claim is true that the deaths in Mexico are skewed towards young and middle-aged adults, then your hypothesis can explain a higher rate of deaths among the infected, but it cannot explain the age skew of the deaths. I.e., wouldn't pollution increase the death rate by the same factor for children, young adults, middle-aged adults and the elderly?
Please STOP spreading this racist, unfounded meme. While Mexico is a developing nation with a "poor" health care system, hospitals in Mexico City and elsewhere are modern, with up-to-date equipment and well-trained personnel.
And even if we assume that the hospitals are bad, one would still have to explain why the deaths are (apparently) so skewed toward young and middle aged adults. The neutral hypothesis is that bad health care would increase mortality uniformly across the whole population, without age biases.
in the US alone there are An estimated 100,000 hospitalizations and about 20,000 deaths occur each year from the plain old flu or its complications... so what is the big deal?
Those numbers reflect old flu strains, for which the population has significant immunity (from a combination of vaccines and antibodies from previous infections). That immunity acts as a natural brake on how much old flu strains can spread, and thus, how many people they can kill.
The big deal is that this new H1N1 strain is one for which nobody has immunity (well, ok, except possibly people who just got it now). This means that it can spread to a much, much higher number than the older, more common strains.
With the grand WHO total of deaths being caused by H1N12009 being EIGHT, and the most well documented death so far being a 23 year old, the whole idea that this is killing otherwise healthy (a BIG assumption, this is Mexico, not the US, the health care system and environmental conditions in Mexico City is not very good in the former and absolutely terrible in the latter case) adults is isn't founded at all.
The WHO grand total of confirmed deaths is low because confirmation of which strain was involved in each specific case is slow. The actual number of deaths so far by the strain is almost certainly significantly higher. To put it more precisely, a large proportion of the cases that have been labeled as suspected swine flu deaths will turn out to be so.
Also, I don't think your Mexican health care and environment objection holds. Given no other data, you would expect that to increase the number of deaths, but not the distribution of deaths across age groups. You need a stronger hypothesis: that the poor health care in Mexico increases the risk of death from H1N1 disproportionately among young adults and middle-aged adults will die from H1N1, compared to children and the elderly.
The one thing that's sure at this point is that our information is quite likely to have very serious holes yet, however.
Seriously, I see Internet doomsdayers saying this, but I don't see the CDC saying this. So, can you provide a link to a reputable source for this? I'm genuinely interested in reading one. If not, then perhaps you should stop spreading it.
The cytokine storm stuff (i.e., the claim that the virus hits healthy people harder than those with compromised immune systems) is really just an early leading hypothesis that's based on the mortality data from Mexico; the virus there is reported to have primarily killed adults 20-50. I really don't think there's any other evidence for it so far.
There's a big puzzle going on right now in that the virus in the USA hasn't been nearly as deadly as in Mexico. From all I've read, this is being actively debated, with hypotheses ranging from flawed data about what's going on in Mexico (i.e., we only know about the most lethal Mexican cases of a much larger outbreak), to the possibility that the USA may have a milder version of the same strain so far.
The thing to stress, however, is that the knowledge about this is still very incomplete, and evolving rapidly.
One of the remarkable facts about this outbreak is that the deaths in Mexico are primarily among healthy adults between 20 and 50--similar to the profile of the Spanish flu of 1918. However, one of the yet unresolved puzzles about the virus is why the mortality figures in Mexico are proportionally so much larger than in the USA, so yeah, we just don't know what's going on yet...
in other words, take the zero out of the roulette, put money on both colors and a number, and just wait it out?
I think it's better to put it in more general terms: make a bet where if the markets go down sharply, you win money proportional to the decline, but if they stay flat or go up, you only suffer a small, constant loss. Basically, a long put.
Hate to break this to you, dude, but writing SQL queries and tuning their performance is a really complex topic. SQL is basically a programming language that throws out Turing completeness in exchange for guaranteed termination--but the grammar of conditions and scalar expressions that it supports is every bit as complex as any programming language.
And then understanding how your queries are optimized and executed gets hairy--syntactic transformations based on relational algebra equivalences, the multitude of table access paths and join methods, the way the eligibility of each of those depends on join conditions (equijoins, semijoins), the process of generating candidate execution plans and estimating their cost based on statistics about the data and the hardware, etc. The relationship between the SQL query you write and what the computer actually does is a lot more indirect and complex than the relationship between the C program you write and what the computer does. There are plenty of people who understand the latter very well, and are hopelessly lost about the former.
And don't get me started about all those programmers who look down on SQL as easy stuff, when they suffer from pretty basic ignorance about it. Like, programmers who can't tell you how many joins their query will need (much less what kind of joins!), don't know how to write subqueries, don't know that EXISTS exists, don't know about the CASE function (or know about CASE but think they should index the columns mentioned in the search clauses), and so on.
Those of you who don't read Portuguese might be missing on the irony of the first site (WARNING: epileptastic!). It's advertising a web site design and creation service. You know, you pay the guy, and he makes you a website like that...
I thought that it was illegal in the US to possess gold in other forms than jewelry or gold coins and considered that strange. Is coins and jewelry what you mean or am I wrong?
It was illegal for a long time (1933-1975). It has been legal for over 25 years now.
If someone invades my house with the intent to harm me or my family, though, I do need a weapon.
If somebody wants to harm you or your family specifically, why would they invade your house that way? Why can't they toss a few Molotov cocktails through your windows, and then shoot you with a rifle when you guys run out of the house? What if they just just monitor your routine and get you in a drive-by shooting when you exit your workplace at the same exit as you always do?
This is again a fantasy scenario. You're assuming a situation where the attacker does exactly what he would have to do in order for you to get the opportunity to successfully use your gun to defend yourself.
In the very rare situation when flight is impractical, your choices are between being a soft unarmed target or being a threatening target.
If you're a threatening target, you're putting your attacker in a situation where he needs to use lethal force in order to survive. I.e., you've escalated the situation into one where one of you will likely get killed.
Note that this doesn't assume that the situation of the unarmed person is a safe one; it is extremely risky. The crucial question here is whether the gun makes you any safer, which it is not at all clear it does. It gives you a shot (literally) at ending the risk to you right away, but it also puts you at a greater risk of being killed.
Having a weapon available is an asset when you NEED it, and can actually GET it.
Unless the other guy kills you to stop you from shooting him.
Your other points all talk about the risks of gun ownership. Responsible gun owners take measures to reduce or eliminate those risks. Irresponsible owners deserve the trouble that they reap.
The problem is that the consequences of irresponsible ownership aren't limited to the irresponsible owners.
Slashdot Mirror
Indeed, I don't think that quote in isolation presents the best case against warrantless GPS tracking, by far. I haven't seen the decision, so for all I know the quote is not representative.
Anyway, in mind this issue isn't about whether GPS tracking, applied to a given, individual case, can collect information that can't be collected by tailing the suspect. The issue is about the American tradition of restricting the power of the police, in order to protect the people from abuse by the authorities. Even if GPS tracking and following somebody around produce the same information, warrantless GPS tracking quite simply gives the police much more opportunity to abuse their power than their current ability to follow suspects.
Having a detective tail a suspect is costly, so the police can be expected to limit its use to the cases where they most expect to uncover evidence of a crime. Warrantless GPS tracking, on the other hand, is cheap, so the police will be tempted to abuse their power by tracking all sorts of people who did nothing wrong. They will undoubtedly uncover some folks' secrets, and there will always be the temptation to use those secrets against them ("tell me what you know about my suspect, and I won't tell your wife about your weekly visits to Motel 8 to see your mistress.").
This issue isn't about whether GPS tracking, applied to one individual case, can collect information that can't be collected by tailing the suspect. The issue is about the restrictions on the power of the police to mess with people. Even if GPS tracking and following somebody around produce the same information, warrantless GPS tracking gives the police plenty more opportunity to abuse their power.
Having a detective tail a suspect is costly, so the police can be expected to limit its use to the cases where they most expect to uncover evidence of a crime. Warrantless GPS tracking, on the other hand, is cheap, so the police will be tempted to abuse their power by tracking all sorts of people who did nothing wrong.
This information is relevant because one of Apple's selling point for the iPhone is that it is a good software platform. If you're attracted to the iPhone because of this reason, Apple's restrictions on what software they allow the platform to run is a very important piece of information, whether you're interested on buying a phone or developing for it. This is the reason why this is important news: it's relevant to deciding whether to buy into the iPhone.
Quite frankly, I think that Apple's restrictiveness in this regard makes me absolutely unwilling to develop software for that platform; they just simply would have too much control over the software, like dictating to me the distribution terms, or cancelling it arbitrarily.
You're making the mistake that concurrency is the same thing as parallelism. It is not. Concurrency is when a program is written in such a way that the order of execution of tasks is highly underspecified; parallelism is the use of multiple execution units to execute concurrent code.
Concurrency isn't just for performance; concurrency is just as much for writing software that can do many things at once. For example, one needs concurrency to have client applications that respond to the user with very low latency while doing some other work in the background. In this case, in fact, the software isn't trying to perform its heavy computations in the absolute minimum time; it's OK to slow down the heavy computation somewhat in order to reduce user interface latency. Have you ever used one of those applications where the whole UI hangs (e.g., won't even draw) while the application does some action, like connecting to a server? That's a failure to provide concurrency.
Contrary to common wisom, the introduction of multicore processors didn't increase our need for good tools for concurrent programming, because we've needed such tools since way before for user interaction. The tools that conventional languages provide for threading and synchronization are too hard to use, leading programmers to introduce far less concurrency into the software than they otherwise could. Also, conventional threads are much too heavyweight for an application to create thousands of them.
Um, can I ask you a small favor?
Um, if you're describing that right, isn't he right to reject your patch? What if I'm a user of another EBDDIC system, and that system uses the choice that's in the library? Does that mean that if your patch is accepted, my patch to undo yours should be equally accepted?
Exactly. Securitization packages up pools of loans into bonds that get given a credit rating by an agency. A lot of bond buyers just go by the bonds' ratings. These bond buyers are the ones who ultimately provide the easy money that ends up being used for the junk mortgages.
Who are these bond buyers? All sorts of banks, and, more worrisome, retirement pensions and bond mutual funds in people's 401k plans. Look, for example, at what happened to Fidelity Ultra-Short Bond Fund. This is a fund that was supposed to be extra-low risk; it lists "preservation of capital" as a goal, and it's supposed to compete with money-market funds and bank accounts. It lost 20% because of exposure to highly-rated subprime securities.
The article isn't seriously claiming that one guy was responsible for it, nor that it was due to a software bug. The article was written by a guy who developed some mortgage securitization software, who tells his story and idly asks himself to what extent he shares responsibility for the debacle.
Um, dude, RTFA. It's a piece by a software developer who wrote a bunch of software for mortgage securitization, telling his story and doing some navel-gazing about whether he should feel guilty about his part in the debacle.
You understood perefectly what he said! You guys are like some kind of grammar, um... strict police.
I thought it was because the more they say it, the truer it becomes...
I'm sure they didn't let any other fake parties in.
Actually, I would claim that that's not a big deal. The big problem is that IPv6 just doesn't provide a sensible migration path from IPv4. The idea that we're all going to wake up one day and switch off IPv4 at once just doesn't cut it. More precisely, an IPv4 node just has no way of talking to an IPv6 node. If we built some sort of standardized IPv4-to-IPv6 NAT technology that was invisible to existing IPv4 nodes, then IPv6 could be adopted gradually and incrementally with minimal cost (the cost could be rolled into the cost of general network gear upgrades).
If the claim is true that the deaths in Mexico are skewed towards young and middle-aged adults, then your hypothesis can explain a higher rate of deaths among the infected, but it cannot explain the age skew of the deaths. I.e., wouldn't pollution increase the death rate by the same factor for children, young adults, middle-aged adults and the elderly?
And even if we assume that the hospitals are bad, one would still have to explain why the deaths are (apparently) so skewed toward young and middle aged adults. The neutral hypothesis is that bad health care would increase mortality uniformly across the whole population, without age biases.
Those numbers reflect old flu strains, for which the population has significant immunity (from a combination of vaccines and antibodies from previous infections). That immunity acts as a natural brake on how much old flu strains can spread, and thus, how many people they can kill.
The big deal is that this new H1N1 strain is one for which nobody has immunity (well, ok, except possibly people who just got it now). This means that it can spread to a much, much higher number than the older, more common strains.
The WHO grand total of confirmed deaths is low because confirmation of which strain was involved in each specific case is slow. The actual number of deaths so far by the strain is almost certainly significantly higher. To put it more precisely, a large proportion of the cases that have been labeled as suspected swine flu deaths will turn out to be so.
Also, I don't think your Mexican health care and environment objection holds. Given no other data, you would expect that to increase the number of deaths, but not the distribution of deaths across age groups. You need a stronger hypothesis: that the poor health care in Mexico increases the risk of death from H1N1 disproportionately among young adults and middle-aged adults will die from H1N1, compared to children and the elderly.
The one thing that's sure at this point is that our information is quite likely to have very serious holes yet, however.
The cytokine storm stuff (i.e., the claim that the virus hits healthy people harder than those with compromised immune systems) is really just an early leading hypothesis that's based on the mortality data from Mexico; the virus there is reported to have primarily killed adults 20-50. I really don't think there's any other evidence for it so far.
There's a big puzzle going on right now in that the virus in the USA hasn't been nearly as deadly as in Mexico. From all I've read, this is being actively debated, with hypotheses ranging from flawed data about what's going on in Mexico (i.e., we only know about the most lethal Mexican cases of a much larger outbreak), to the possibility that the USA may have a milder version of the same strain so far.
The thing to stress, however, is that the knowledge about this is still very incomplete, and evolving rapidly.
One of the remarkable facts about this outbreak is that the deaths in Mexico are primarily among healthy adults between 20 and 50--similar to the profile of the Spanish flu of 1918. However, one of the yet unresolved puzzles about the virus is why the mortality figures in Mexico are proportionally so much larger than in the USA, so yeah, we just don't know what's going on yet...
I think it's better to put it in more general terms: make a bet where if the markets go down sharply, you win money proportional to the decline, but if they stay flat or go up, you only suffer a small, constant loss. Basically, a long put.
Hate to break this to you, dude, but writing SQL queries and tuning their performance is a really complex topic. SQL is basically a programming language that throws out Turing completeness in exchange for guaranteed termination--but the grammar of conditions and scalar expressions that it supports is every bit as complex as any programming language.
And then understanding how your queries are optimized and executed gets hairy--syntactic transformations based on relational algebra equivalences, the multitude of table access paths and join methods, the way the eligibility of each of those depends on join conditions (equijoins, semijoins), the process of generating candidate execution plans and estimating their cost based on statistics about the data and the hardware, etc. The relationship between the SQL query you write and what the computer actually does is a lot more indirect and complex than the relationship between the C program you write and what the computer does. There are plenty of people who understand the latter very well, and are hopelessly lost about the former.
And don't get me started about all those programmers who look down on SQL as easy stuff, when they suffer from pretty basic ignorance about it. Like, programmers who can't tell you how many joins their query will need (much less what kind of joins!), don't know how to write subqueries, don't know that EXISTS exists, don't know about the CASE function (or know about CASE but think they should index the columns mentioned in the search clauses), and so on.
Those of you who don't read Portuguese might be missing on the irony of the first site (WARNING: epileptastic!). It's advertising a web site design and creation service. You know, you pay the guy, and he makes you a website like that...
It was illegal for a long time (1933-1975). It has been legal for over 25 years now.
If somebody wants to harm you or your family specifically, why would they invade your house that way? Why can't they toss a few Molotov cocktails through your windows, and then shoot you with a rifle when you guys run out of the house? What if they just just monitor your routine and get you in a drive-by shooting when you exit your workplace at the same exit as you always do?
This is again a fantasy scenario. You're assuming a situation where the attacker does exactly what he would have to do in order for you to get the opportunity to successfully use your gun to defend yourself.
If you're a threatening target, you're putting your attacker in a situation where he needs to use lethal force in order to survive. I.e., you've escalated the situation into one where one of you will likely get killed.
Note that this doesn't assume that the situation of the unarmed person is a safe one; it is extremely risky. The crucial question here is whether the gun makes you any safer, which it is not at all clear it does. It gives you a shot (literally) at ending the risk to you right away, but it also puts you at a greater risk of being killed.
Unless the other guy kills you to stop you from shooting him.
The problem is that the consequences of irresponsible ownership aren't limited to the irresponsible owners.
Well, you are at enormous odds with the USA gun lobby, in that case.