It's simply missing a single dash between 'slot' and 'in'. However, it is nonsense as printed. The fact that it's nonsense might provoke me to try and work out what was supposed to be written. Dropping the word 'in' would give me the answer quite quickly.
However, I tend to be surrounded by people who aren't native English speakers, so I perform this kind of error correction almost instinctively.
It's easier to just think that no-one actually saw the warning.
DRM is irrelevant. The thing that makes those disks not permitted to use the logo is that they do not adhere to the red book specification for error recovery on the read signal. Assuming a 10^-3 bit read error rate, there should be less than 10^-9 bit error rate in the decoded signal due to the various error correction mechanisms. These non-CDs do not have that same property. The fact that this buggering of the recorded signal is done for DRM ends isn't actually important at all.
No part of the GPL2 requires them to give the source to any third party, not even 3b. As long as they abide by 3a or 3c, then they don't need to do 3b. They used the word 'or', because they meant 'or'.
Given that they're not distributing the binary to me, they can ask me to jump naked through flaming hoops before giving the source to me, and then still refuse to give it to me.
Will it solve the Halting Problem too? If so, someone better resurrect Turing, Goedel and Post, as they'll want to rejigg the conclusions from their papers.
He also doesn't have a clue how to combine benchmark results. Unless the individual sub-tests are deliberately weighted, you shouldn't use an arithmetic mean (or a sum), instead you should use a geometric mean. A sum without weighting gives more importance to tests that run for longer, which clearly biases the final result.
I was speaking to my (Finnish) boss about his (French) boss as we were about to take a business trip from Finland to France. In Finnish, 'boss' is 'pomo', and 'bomb' is 'pommi', but I didn't know that at the time, and I happily mispronounced everything. I wondered why my bomb was very twitchy, but he didn't want to explain it to me while we were in the airport. At about that point, I received an SMS from my girlfriend, for whom, in the context of sending or receiving SMSs, my nickname is 'bomb' (simple puzzle - can you now guess what her name is?), which I vocalised. My bomb told me he never wanted to fly with me again...
"Since you don't pay for FireFox, there is really no reason not to upgrade."
You've never worked in an enterprise environment, have you? Rolling out a new version company wise simply because a new version is available and free is a great way for needing an IT department 10 times larger than if you were sane, and didn't do such crazy things. And of course that costs, so your "don't pay" argument is completely blown out of the water.
"Don't upgrade until you have to" is the more sensible and more common enterprise procedure. (Which is mostly security threats that can't be stopped at the various firewalls.)
Clients/robots/etc. do not _take_ data off a server, they _request_ data off the server. The server decides if the client has permission, and then serves that content if it does.
This 'implicit global permission' you speak of is simply a configuration of the website. There's nothing 'implicit' about it, it's a particular configuration that you've actively chosen to have. Sure, your 'choice' process may have been nothing more than "I'll accept the defaults", but that's still an active choice. If a client's request was granted, it had permission to access the data. That's the definition of permission. If you want to restrict permissions, then use.ht* and robots.txt, and logins, and captchas, etc. If you don't do that, then you are _chosing_ to serve everyone everything. Your choice, don't complain about it.
It has been proven that such concatenation isn't as strong as the sum of the strengths as the two hashes; if you can crack one of the component hashes, then you can generally generate a vast number of collisions to throw at the rest other hash. Sure, it's stronger than the strongest individually, but it's best to just use a single full-width hash.
Nope, this attack is new. This is taking fixed prefixes, and appending a suffix to create the collision. Previous attacks required being able to put something _before_ your fixed payloads.
I've done some research - roughly meaning I asked some bright people to enlighten me:-) - and I have a simple explanation!
Statistics show that the death rate doubles every 10 years of age, with a pretty good exponential fit: http://www.cdc.gov/nchs/datawh/statab/unpubd/mortabs/gmwk23a.htm
So look at things this way: Smoking/effectively/ makes you 12 years older.
Conclusions: 1) you'll be just over twice as likely to cop it as non-smokers of the same age, according to that exponential fit 2) you'll have 12 years less life.
I simply didn't realise that oldies died so much, but when you've factored that into it, the rest drops out quite easily. For more of a background, see the usenet thread on rec.puzzles with the subject line "Kinda real-world puzzle". In particular Christopher Night's contributions to the thread.
I'd appreciate it if you could give some feedback whether my "simple" explanation does in fact make sense, else I shall have to find some other approach.
However, the death rate being 2x higher _does_ mean that smokers are dying twice as often, which was your original query.
You're not a moron, your brain wasn't off, you asked a perfectly valid question.
If the death rate is x per thousand per year, then, assuming steady state, the chance of dying every year is x/1000, and the average length of time an individual will have to wait before his death is 1000/x. Double x, and the length of time you'll last is halved.
The claim really is that they are dying at twice the rate whether that rate is viewed as ratio of population per year, or as each individual's chance of dying per year. However, I'm pretty sure that the figures do not bear this out, so there must be some assumption that's not being stated. Note, for example, that the 'wrongdiagnosis' page also quotes this statistic: "Average life years lost for Smoking: 12 years (NIA)". Which implies that the average non-smoker might live for 60 years after reaching adulthood, and that the average smoker only lives 48 years. That implies that the death rate is 1.25x as large, not 2-3x as large for smokers.
Perhaps the death rates have been normalised by subtracting some base death rate for causes that are independent of whether you're a smoker or not, such as dying from unnatural causes (car accidents, homicides, suicide, war). So that the death rate for non-smokers would be (b+x) and for smokers (b+2*x). Or perhaps by 'smokers' they mean 'smokers of more than 2 packs of cigarettes per day', not including just occasional smokers.
Yes, it's hard to know who's actually a developer, and who's simply interested enough in the development to enter discussions on the buglists. Typical average user isn't botherred, I'm sure. (I'm not, 99% of the time to be honest.)
Thank you for the test in FF3. I did send a 'this page doesn't render correctly' feedback report to the FF crew but if it's fixed in 3, then let's wait for 3. Of course, the 'bug' is google's asking for a redirect to the very same page, that's just inane. I raised it as a bug with the author of NoScript too, as I had 'forbid meta refresh redirects in noscript elements' enabled at the time.
After scores of firefox related stories on/., and dozens of complaints about the leakage, some of which are gainsaid, some of which are countered with links to mozilla's bugzilla page, I'm 100% sure I've encountered sayings like "Not releasing memory is a feature, not a bug". Quite which bug report, I haven't a clue, there are hundreds of thousands of firefox bug reports.
Incidentally, with nothing to do with this discussion at all (just doing some research for an article), I discovered a perfect example of a killer memory leak: http://www.blacksmithinstitute.org/ten.php with javascript blocked, there's an iframe with a meta refresh that reloads itself. Bye bye RAM - one way, no returns. If you do have FF3, then it might be worth seeing what it's behaviour is. I'm not installing FF3 until it becomes part of the distribution I run, which may be many months.
One concrete weakness of this attack is that it permits you to reverse-engineer "secure" sessions _before_ you got admin privilege, as the random number generator can be 'rewound'.
So-called forward security (yes, looking at things in the past is 'forward':-) ) is an important trait, and MS's scheme is missing it.
Slashdot Mirror
It's simply missing a single dash between 'slot' and 'in'. However, it is nonsense as printed. The fact that it's nonsense might provoke me to try and work out what was supposed to be written. Dropping the word 'in' would give me the answer quite quickly.
However, I tend to be surrounded by people who aren't native English speakers, so I perform this kind of error correction almost instinctively.
It's easier to just think that no-one actually saw the warning.
DRM is irrelevant. The thing that makes those disks not permitted to use the logo is that they do not adhere to the red book specification for error recovery on the read signal. Assuming a 10^-3 bit read error rate, there should be less than 10^-9 bit error rate in the decoded signal due to the various error correction mechanisms. These non-CDs do not have that same property. The fact that this buggering of the recorded signal is done for DRM ends isn't actually important at all.
No part of the GPL2 requires them to give the source to any third party, not even 3b. As long as they abide by 3a or 3c, then they don't need to do 3b. They used the word 'or', because they meant 'or'.
Given that they're not distributing the binary to me, they can ask me to jump naked through flaming hoops before giving the source to me, and then still refuse to give it to me.
Sign up as a developer, download the source, and find out:
http://www.splashtop.com/developer.php
How about scripting such things? The following is all one line. Replace 'networksolutionssuckass' with whatever you want.
wget --post-data='TLDs=.com&domainNames=networksolutionssuckass&method-submit=method-submit&Search=/domain-name-registration/domain-name-search-results.jsp¤tPage=/home.jsp;jsessionid=5e337df9d98b6ffffffffc065d3ac7937db7:+cjA?layoutIdIndex=1&formTargetPage=/domain-name-registration/index.jsp' http://www.networksolutions.com/domainSearch.do;jsessionid=5e337df9d98b6ffffffffc065d3ac7937db7:+cjA
Let's hope for a class action lawsuit with punitive damages for every domain that they've squatted. That script could be a millionaire...
Will it solve the Halting Problem too? If so, someone better resurrect Turing, Goedel and Post, as they'll want to rejigg the conclusions from their papers.
I'm sure it's fine as long as you aim it at a long-persistence phosphor wall.
You probably didn't say it in a "stupid little blog". (Yes, I RTFA!)
He also doesn't have a clue how to combine benchmark results. Unless the individual sub-tests are deliberately weighted, you shouldn't use an arithmetic mean (or a sum), instead you should use a geometric mean. A sum without weighting gives more importance to tests that run for longer, which clearly biases the final result.
Is the acid test of a Ducati motorbike whether Adriana Stoner née Tuchyna can ride it?
I was speaking to my (Finnish) boss about his (French) boss as we were about to take a business trip from Finland to France. In Finnish, 'boss' is 'pomo', and 'bomb' is 'pommi', but I didn't know that at the time, and I happily mispronounced everything. I wondered why my bomb was very twitchy, but he didn't want to explain it to me while we were in the airport. At about that point, I received an SMS from my girlfriend, for whom, in the context of sending or receiving SMSs, my nickname is 'bomb' (simple puzzle - can you now guess what her name is?), which I vocalised. My bomb told me he never wanted to fly with me again...
He's obviously also not heard of Randall Schwartz.
"Since you don't pay for FireFox, there is really no reason not to upgrade."
You've never worked in an enterprise environment, have you? Rolling out a new version company wise simply because a new version is available and free is a great way for needing an IT department 10 times larger than if you were sane, and didn't do such crazy things. And of course that costs, so your "don't pay" argument is completely blown out of the water.
"Don't upgrade until you have to" is the more sensible and more common enterprise procedure. (Which is mostly security threats that can't be stopped at the various firewalls.)
Clients/robots/etc. do not _take_ data off a server, they _request_ data off the server. The server decides if the client has permission, and then serves that content if it does.
.ht* and robots.txt, and logins, and captchas, etc. If you don't do that, then you are _chosing_ to serve everyone everything. Your choice, don't complain about it.
This 'implicit global permission' you speak of is simply a configuration of the website. There's nothing 'implicit' about it, it's a particular configuration that you've actively chosen to have. Sure, your 'choice' process may have been nothing more than "I'll accept the defaults", but that's still an active choice. If a client's request was granted, it had permission to access the data. That's the definition of permission. If you want to restrict permissions, then use
So you've decided to enter into a discussion about IRC, pretending to know something about it, and you don't know about /away?
Sheesh.
It has been proven that such concatenation isn't as strong as the sum of the strengths as the two hashes; if you can crack one of the component hashes, then you can generally generate a vast number of collisions to throw at the rest other hash. Sure, it's stronger than the strongest individually, but it's best to just use a single full-width hash.
"someone signed as trusted a binary file that contained malicious code in the first place,"
Just plain wrong. Read the article.
Nope, this attack is new. This is taking fixed prefixes, and appending a suffix to create the collision. Previous attacks required being able to put something _before_ your fixed payloads.
I've done some research - roughly meaning I asked some bright people to enlighten me :-) - and I have a simple explanation!
/effectively/ makes you 12 years older.
Statistics show that the death rate doubles every 10 years of age, with a pretty good exponential fit:
http://www.cdc.gov/nchs/datawh/statab/unpubd/mortabs/gmwk23a.htm
So look at things this way:
Smoking
Conclusions:
1) you'll be just over twice as likely to cop it as non-smokers of the same age, according to that exponential fit
2) you'll have 12 years less life.
I simply didn't realise that oldies died so much, but when you've factored that into it, the rest drops out quite easily. For more of a background, see the usenet thread on rec.puzzles with the subject line "Kinda real-world puzzle". In particular Christopher Night's contributions to the thread.
I'd appreciate it if you could give some feedback whether my "simple" explanation does in fact make sense, else I shall have to find some other approach.
However, the death rate being 2x higher _does_ mean that smokers are dying twice as often, which was your original query.
You're not a moron, your brain wasn't off, you asked a perfectly valid question.
If the death rate is x per thousand per year, then, assuming steady state, the chance of dying every year is x/1000, and the average length of time an individual will have to wait before his death is 1000/x. Double x, and the length of time you'll last is halved.
The claim really is that they are dying at twice the rate whether that rate is viewed as ratio of population per year, or as each individual's chance of dying per year. However, I'm pretty sure that the figures do not bear this out, so there must be some assumption that's not being stated. Note, for example, that the 'wrongdiagnosis' page also quotes this statistic:
"Average life years lost for Smoking: 12 years (NIA)". Which implies that the average non-smoker might live for 60 years after reaching adulthood, and that the average smoker only lives 48 years. That implies that the death rate is 1.25x as large, not 2-3x as large for smokers.
Perhaps the death rates have been normalised by subtracting some base death rate for causes that are independent of whether you're a smoker or not, such as dying from unnatural causes (car accidents, homicides, suicide, war). So that the death rate for non-smokers would be (b+x) and for smokers (b+2*x). Or perhaps by 'smokers' they mean 'smokers of more than 2 packs of cigarettes per day', not including just occasional smokers.
Either way, the 2-3x figure is suss.
Yes, it's hard to know who's actually a developer, and who's simply interested enough in the development to enter discussions on the buglists. Typical average user isn't botherred, I'm sure. (I'm not, 99% of the time to be honest.)
Thank you for the test in FF3. I did send a 'this page doesn't render correctly' feedback report to the FF crew but if it's fixed in 3, then let's wait for 3. Of course, the 'bug' is google's asking for a redirect to the very same page, that's just inane. I raised it as a bug with the author of NoScript too, as I had 'forbid meta refresh redirects in noscript elements' enabled at the time.
After scores of firefox related stories on /., and dozens of complaints about the leakage, some of which are gainsaid, some of which are countered with links to mozilla's bugzilla page, I'm 100% sure I've encountered sayings like "Not releasing memory is a feature, not a bug". Quite which bug report, I haven't a clue, there are hundreds of thousands of firefox bug reports.
Incidentally, with nothing to do with this discussion at all (just doing some research for an article), I discovered a perfect example of a killer memory leak: http://www.blacksmithinstitute.org/ten.php with javascript blocked, there's an iframe with a meta refresh that reloads itself. Bye bye RAM - one way, no returns. If you do have FF3, then it might be worth seeing what it's behaviour is. I'm not installing FF3 until it becomes part of the distribution I run, which may be many months.
You don't agree with me completely as you think that developers have never denied that there are leaks. They have.
One concrete weakness of this attack is that it permits you to reverse-engineer "secure" sessions _before_ you got admin privilege, as the random number generator can be 'rewound'.
:-) ) is an important trait, and MS's scheme is missing it.
So-called forward security (yes, looking at things in the past is 'forward'