So could this possibly lead to a way to "drain" radioactive waste by exposing it to a high neutrino flux? Or is it the other way around... does a higher flux slow it down and we're already near the limit of the highest speed of decay?
I think your comment is pretty irrelevant since the TSA has only gotten worse since it's inception. Not only has it made mistakes, but it has expanded and pursued its mistakes to a point where, like the GP implied, we have to take a step back and say "this has gotten a little out of control."
Maybe you could forward some spam from, say, a gmail account to your address in question. If it doesn't make it through to your server then you have a definitive record to confront your ISP with. Or, if they do get through, maybe you should buy a lottery ticket because your the luckiest admin on slashdot!
You sound like a textbook on logic explaining what a false dichotomy is; there's a big difference between the government monitoring citizens without their consent and people taking personal photos in public places, and there's most definitely a lot of gray area between them.
Very good points, I see what you're saying, maybe both of our original comments were two sides of a false dichotomy; insurance doesn't mean nothing, but it certainly isn't everything.
Whether or not you get money out of them in compensation for the lost data is almost non-important
Maybe for a home user, but usually for a business time actually does = money, and the two are relatively interchangeable. One day of work = $x, and insurance means a lot. And if you'd actually read TFA, you would know that one of the companies involved, Nirvanix, is a business oriented cloud-storage company.
Maybe what you meant to say was "Insurance means nothing to me."
"Well then you'd better go catch it before it trips over your address space layout randomization and skins its knees on the data execution prevention!"
Why don't you go a step further and just assume that everyone does their illegal sharing in a virtual machine? Hell, you could change the MAC every day. The possibilities for error by tying an IP to a MAC are pretty boundless.
In case anyone has forgotten, CSIRO is the group that wouldn't give a Letter of Assurance to the IEEE with regards to its 802.11n patents and who sued Buffalo et al. I guess they really do use those wireless patents after all!
I check./ and ars constantly throughout the day, I had already seen and commented on this one here when ars put theirs up. Ars' article is, without a doubt, more informative and insightful than the one linked to in the OP. If you think that./ always links to the "best" article on a given topic 100% of the time, then you are gravely mistaken. I'm not ripping on./ in any way (if anything I was ripping on the OP and linked article), all I was doing was trying to add to the discussion by pointing to an article that had more info. Sorry for trying to be helpful and reading more than one tech news site.
You are correct; it has been known for years. The poster clearly didn't read the article. The actual news is that limiting nitrogen is bad, and causes more algae blooms and eutrophication. Apparently people thought that along with phosphorus, nitrogen should also be controlled, this experiment confirmed that it does not.
Carpenter predicts that a single-minded focus on nitrogen control would have disastrous consequences for aquatic resources around the world.
But why should a secret URL not be a decent security feature?
You seem to be a proponent of security through obscurity; please hand over your/. gun and turn in you nerd badge.
Seriously though, when I take a picture on my mobile phone and upload it to my provider's site, I feel like it's understood that someone would need a password to see my media. Hiding a password in a URL isn't an option because of the reason you so clearly outlined with services like Google Toolbar.
I think what pageexec (the "antagonist" in the referenced thread) was trying to say was that he feels a lot of the developers don't follow Documentation/SecurityBugs in their commits in a consistent way. He's saying that when people post commits for regular bugs, they include a decent amount of data about what they fixed, but if it's a security bug, people are posting a minimal amount in their commits. Apparently in Documentation/SecurityBugs, it says that full disclosure is the policy, but what he's seeing is less than full disclosure in practice. That is what the thread is actually about, Linus' opinions are ancillary to that point.
He's just saying that it seems to him that what is written as policy for kernel devs is not what they're actually doing, so they should either change the policy or change their commits. If the changelogs don't conform to policy, at some point somewhere downstream devs are going to miss something because the policy doesn't match the practice, and that's what's a security risk.
Slashdot Mirror
YES. THE WORDS. THEY ARE TRUE.
hahaha, I definitely cracked a smile at that one, thanks. I do enjoy idleispants, though.
http://slashdot.org/tags/badsummary
slashdot's been wrong in the past.
So could this possibly lead to a way to "drain" radioactive waste by exposing it to a high neutrino flux? Or is it the other way around... does a higher flux slow it down and we're already near the limit of the highest speed of decay?
I think your comment is pretty irrelevant since the TSA has only gotten worse since it's inception. Not only has it made mistakes, but it has expanded and pursued its mistakes to a point where, like the GP implied, we have to take a step back and say "this has gotten a little out of control."
Maybe you could forward some spam from, say, a gmail account to your address in question. If it doesn't make it through to your server then you have a definitive record to confront your ISP with. Or, if they do get through, maybe you should buy a lottery ticket because your the luckiest admin on slashdot!
So Google Street View is a state trying to monitor the acts of citizens?
From the OP:
Privacy, Police State!
The OP was the one who brought up the idea of a state. I think it's pretty clear he's not talking about people's reactions to Google Street View.
Choose one.
No.
You sound like a textbook on logic explaining what a false dichotomy is; there's a big difference between the government monitoring citizens without their consent and people taking personal photos in public places, and there's most definitely a lot of gray area between them.
why would they NOT use doubleclick's cookies? Did you think they paid $LARGEAMOUNT for doubleclick just to shut them down?
"$LARGEAMOUNT" = /s/\/d/$PUREEVIL/;
Very good points, I see what you're saying, maybe both of our original comments were two sides of a false dichotomy; insurance doesn't mean nothing, but it certainly isn't everything.
Whether or not you get money out of them in compensation for the lost data is almost non-important
Maybe for a home user, but usually for a business time actually does = money, and the two are relatively interchangeable. One day of work = $x, and insurance means a lot. And if you'd actually read TFA, you would know that one of the companies involved, Nirvanix, is a business oriented cloud-storage company.
Maybe what you meant to say was "Insurance means nothing to me."
your running kernel...
"Excuse me, is your kernel running?"
"Yes..."
"Well then you'd better go catch it before it trips over your address space layout randomization and skins its knees on the data execution prevention!"
Why don't you go a step further and just assume that everyone does their illegal sharing in a virtual machine? Hell, you could change the MAC every day. The possibilities for error by tying an IP to a MAC are pretty boundless.
I have a teletype connected to a tin can that crosses the border with a long peice of twine, connected to another tin can connected to a modem.
Yes, well, you see, they inductively deduced this concusion...
In case anyone has forgotten, CSIRO is the group that wouldn't give a Letter of Assurance to the IEEE with regards to its 802.11n patents and who sued Buffalo et al. I guess they really do use those wireless patents after all!
I check ./ and ars constantly throughout the day, I had already seen and commented on this one here when ars put theirs up. Ars' article is, without a doubt, more informative and insightful than the one linked to in the OP. If you think that ./ always links to the "best" article on a given topic 100% of the time, then you are gravely mistaken. I'm not ripping on ./ in any way (if anything I was ripping on the OP and linked article), all I was doing was trying to add to the discussion by pointing to an article that had more info. Sorry for trying to be helpful and reading more than one tech news site.
Arstechnica now has a much better writeup of the situation:
http://arstechnica.com/news.ars/post/20080731-opt-in-or-opt-out-street-view-case-echoes-privacy-debate.html
Announcing Google Home View!
Just click on a house to see pictures of the interior and it's occupants in the restroom!
Called 911 for a tuna sandwich, $400 fine.
Called 911 for the capital of Spain, 2 weeks community service.
Called 911 for getting flamed on slashdot, priceless.
Carpenter predicts that a single-minded focus on nitrogen control would have disastrous consequences for aquatic resources around the world.
What is username/password if not security via obscurity then? You can brute force them just as easily you can brute force an URL.
Fair enough, the more I think about it the more I understand your point.
But why should a secret URL not be a decent security feature?
You seem to be a proponent of security through obscurity; please hand over your /. gun and turn in you nerd badge.
Seriously though, when I take a picture on my mobile phone and upload it to my provider's site, I feel like it's understood that someone would need a password to see my media. Hiding a password in a URL isn't an option because of the reason you so clearly outlined with services like Google Toolbar.
I knew it couldn't last. Oh well. There is always FreeBSD.
Linus Torvalds, from the very email in question,
...I think the OpenBSD crowd is a bunch of masturbating monkeys...
Shazam! Take that gatkinso!
I think what pageexec (the "antagonist" in the referenced thread) was trying to say was that he feels a lot of the developers don't follow Documentation/SecurityBugs in their commits in a consistent way. He's saying that when people post commits for regular bugs, they include a decent amount of data about what they fixed, but if it's a security bug, people are posting a minimal amount in their commits. Apparently in Documentation/SecurityBugs, it says that full disclosure is the policy, but what he's seeing is less than full disclosure in practice. That is what the thread is actually about, Linus' opinions are ancillary to that point.
He's just saying that it seems to him that what is written as policy for kernel devs is not what they're actually doing, so they should either change the policy or change their commits. If the changelogs don't conform to policy, at some point somewhere downstream devs are going to miss something because the policy doesn't match the practice, and that's what's a security risk.