I comment things that are non intuitive. I comment things that I *think* may be non intuitive. I comment things that I think someone else might have some difficulty understanding, because I happened to be deep into a code burn and consequently wrote something pretty tight, pretty sweet, but also pretty obfuscated. Finally, I comment things that I think *I* may not understand when I go back and look at the code again 3 months from now.
I basically have the same set of criteria as you do and I make an effort to follow them... only to have my hopes dashed when I see my comments removed in future patches.
Comments that state what the code does are pretty useless, since the code says the same thing.
Not true! Code that says "i++;// increment i" is obviously useless. But when you comment the overall effect of a block of code, this has several advantages:
a) It saves the reader the time of figuring it out for themselves. b) It acts as a sanity check.
I don't know about you, but when maintaining code that was written by someone else, I am often faced with a situation where it is clear *what* the code does, but not what it was *intended* to do.
I.e. there may have been a bug or a poor design decision in the original code, but without a comment, how can I tell whether the code originally did A but someone changed it to do B or whether it was meant to do B but there was a bug. If I find a case where there is a comment that doesn't match the code then I can usually track down the revision history and figure out which way is correct.
Why comment the range of values a variables can contain. Such a comment will rarely be updated when someone decides to change the range.
I will occasionally write a comment that mentions the range of values just because it probably makes the code easier to understand. I hope the next person to read the comment will be a bit skeptical. I try to include a date when I do this. E.g. "We support up to 10 entries here (as of May 2004) because that's all that will fit in a 1500 byte packet."
You might be wondering what this technology would have over bluetooth. Well have you ever used bluetooth? You inevitably have to fiddle with it for minutes to find the menu option that lists the devices that you have already registered with and then fiddle more to map the name that is on the menu with the device
Sounds like you are just complaining about some flaws in the implementation of bluetooth rather than actually suggesting an advantage of the HAN approach. How does HAN really solve these problems? You still have to deal with the problem of disambiguation. You still have to have some kind of authorization mechanism so that every device you touch doesn't have instant access to every other device you touch. (Can you imagine a computer virus that literally spreads by touch?)
There are ways that the UI for bluetooth can be improved - to an extent. Security is always inconvenient. That's how Microsoft can stay ahead. Just ignore security and make your UIs better.
The concern is not so much that the method described in this break is feasible on today's hardware, or even that this method will get cheaper and cheaper as hardware gets faster. The BIG concern is that this method provides insight in to the SHA-1 in general, and will be used by others to come up with more efficient breaks or more egregious flaws.
But that's not what seems to be happening. We've seen the same basic hack applied to multiple algorithms now, but we haven't seen the Md5 hacks improved for MD5.
Despite the flames your post has drawn, the fact is there are off-the-shelf spyware programs that steal your banking info and let someone liquidate your account. That may not kill anyone, nut it's sure a pain in the ass.
Let's say that this vulnerability reduces the average time needed to find a collision from 2^48 tries via the Birthday paradox (If this isn't a 96-bit hash, then I really need to get more sleep) to 2^32 tries. That's over 65,000 times faster, but you know why I'm not worried? That's still over 4,000,000,000 ISO files that the attacker would have to try before hitting on one that's got the wanted characteristics and the correct digest to boot,
You're misapplying the birthday paradox. The corrected statement is that the attacker would have to generate 4 million fake ISOs in order to have a high probability of generating a hash that collides with any one of 4 million real ISOs.
And that's *IF* your assumption was correct, which it most likely isn't. Cryptographic attacks aren't necessarily additive. You can't just assume that attack A reduces the key space by 10 bits and attack B reduces the key space by 20 bits so together they reduce the key space by 30 bits. It's not that simple.
I thought the NSA already did this. I used to work for a security company, and I have vague memories of the NSA evaluating our product on behalf of the US government (i.e. to secure non-military traffic). We even had to drive off to a secure building in order to teleconference with them.
That is a good point, but it doesn't mean that the boot process can't be sped up quite a bit. It would especially be useful on laptops, or for people who like to save electricity by shutting down their computers when not in use.
It would probably be most useful for the Linux kernel developers themselves.
Sure many of our neurons can self organize. We need that in order to learn. However, there are clearly some behaviours that can only be explained by instinct.
Some hardcoded area in our brains knows how to recognize faces, and regardless of whether we understand *how* it works, we can locate the area that does it.
For describing an algorithm as being tantamount to thought, I think we have a mental obstacle in that we are unwilling to say that an algorithm is conscious unless we can't perceive that it is rule based. If an algorithm produces intelligent esults that couldn't be foreseen by examining the algorithms then philosophers will be more willing to accept it as intelligent.
I think the problem is not that we have an inadequate physical model of synapse formation. The problem is that the human brain is not a blank neural network. It is pre-trained by genetics, which gives us instincts and motivations and fears. Simulating instincts and also early childhood is likely to be the stumbling block in modern AI.
Your argument might hold some weight if carmaking was not aleady an international business. But it is. Defending your earlier statement by dividing the market into 3 groups of 3 smacks more of numerology than logic.
I switched to Dvorak for awhile. I liked it in general (although it was a pain to remember where all the symbolic keys were).
The problem was that I often had to solve a problem at a co-worker's desk and switching between Dvorak and Qwerty was just too hard. The worst case of this was when I had to write some sample code (under time pressure) during a job interview. I didn't get the job (although probably not for that reason).
the key question is, why was someone with obviously no grasp of proper application security design allowed to use identification numbers as passwords? any competent person in the field will tell you that they ARE NOT PASSWORDS and SHOULD NEVER BE USED AS PASSWORDS.
Heh... that should be MUST NOT be used as passwords.:-)
The funny thing is that their security consultant is Scott Bradner, who came up with the MUST, SHOULD, etc. terminology for RFCs. He was also transport area director at the IETF (but not security area director).
The other funny thing is that his parents apparently gave him the middle name beginning with O, giving him the initials SOB.
Kind of a mixed bag... Wordperfect: used initial success of Excel (not developed by Microsoft, BTW), created an integrated Office bundle (including Word) and started practically giving it away to businesses along with Windows.
Netscape: Umm, this is the case that got Microsoft convicted as an illegal monopoly, remember? If this case does not completely prove my allegations, none will.
Accusing MS of predatory pricing on/.? Darest the pot call the kettle black?
Of course, this does pose a problem: currently, we're using up resources on a grand scale. And if our population growth continues as the average consumption of individuals go up, we may end up seeing a problem with a shortage of resources. This will cause prices for items to go up, which means that the increased salaries will have decreased worth
Yes, it is true. This is the major fallacy of the pro-globalization policies that are being thrust upon us. (this is pretty much the case now in the US: you can live like a king in Beijing on $20,000 but in New York you'd barely be scraping by).
I don't think you can live like a king in Beijing for $20k. For one thing, prime Beijing real-estate is pretty expensive. Also, have you seen the way their kings used to live?
The flaws with outsourcing to China are two-fold:
1. Programmers are cheaper, but are generally far less qualified. 2. Everyone from partners to manufacturers and even the government is out to steal your technology.
I don't know the exact reason for #1. It's probably a combination of:
a) General lack of history with effective software development practices. b) Programming is considered to be monkey work, whereas sales and marketing are held in high esteem. c) Anyone with a higher education tends to emigrate. (Partly because of reason b.)
I don't think most people think a car is like software - they think computers are like cars. They're both big expensive machines which everyone uses whether they want to or not, most people rely on them, and very few people know how to fix. After that though the analogy breaks down a bit. Yes Mr. Gates it would be ludicrous for the government to tell you you have to buy your tires separately from your car (analogy he was hoisting when the whole IE Bundling thing went down) but at least tires can be removed from the car.
I think the standard/. cliche is that when your car breaks down you don't have to take it back to the manufacturer to get it fixed - you just take it to your local mechanic. So why should closed source software companys be allowed to have a monopoly on support?
Slashdot Mirror
I comment things that are non intuitive. I comment things that I *think* may be non intuitive. I comment things that I think someone else might have some difficulty understanding, because I happened to be deep into a code burn and consequently wrote something pretty tight, pretty sweet, but also pretty obfuscated. Finally, I comment things that I think *I* may not understand when I go back and look at the code again 3 months from now.
I basically have the same set of criteria as you do and I make an effort to follow them... only to have my hopes dashed when I see my comments removed in future patches.
-a
Comments that state what the code does are pretty useless, since the code says the same thing.
// increment i" is obviously useless. But when you comment the overall effect of a block of code, this has several advantages:
Not true! Code that says "i++;
a) It saves the reader the time of figuring it out for themselves.
b) It acts as a sanity check.
I don't know about you, but when maintaining code that was written by someone else, I am often faced with a situation where it is clear *what* the code does, but not what it was *intended* to do.
I.e. there may have been a bug or a poor design decision in the original code, but without a comment, how can I tell whether the code originally did A but someone changed it to do B or whether it was meant to do B but there was a bug. If I find a case where there is a comment that doesn't match the code then I can usually track down the revision history and figure out which way is correct.
-a
Why comment the range of values a variables can contain. Such a comment will rarely be updated when someone decides to change the range.
I will occasionally write a comment that mentions the range of values just because it probably makes the code easier to understand. I hope the next person to read the comment will be a bit skeptical. I try to include a date when I do this. E.g. "We support up to 10 entries here (as of May 2004) because that's all that will fit in a 1500 byte packet."
-a
Geez... too bad there's a karma cap, huh?
I'll bet your book gets 100 d/l's from this thread alone.
-a
You might be wondering what this technology would have over bluetooth. Well have you ever used bluetooth? You inevitably have to fiddle with it for minutes to find the menu option that lists the devices that you have already registered with and then fiddle more to map the name that is on the menu with the device
Sounds like you are just complaining about some flaws in the implementation of bluetooth rather than actually suggesting an advantage of the HAN approach. How does HAN really solve these problems? You still have to deal with the problem of disambiguation. You still have to have some kind of authorization mechanism so that every device you touch doesn't have instant access to every other device you touch. (Can you imagine a computer virus that literally spreads by touch?)
There are ways that the UI for bluetooth can be improved - to an extent. Security is always inconvenient. That's how Microsoft can stay ahead. Just ignore security and make your UIs better.
-a
Who needs fancy things like PGP? I encrypt all my sensitive data in ROT-13, and it hasn't been cracked yet!
Are ROT-13 jokes still +1 funny?
I thought we had moved past ROT-13 and ROT-26 and you had to posit ROT-39 or up in order to get a rise out of people.
-a
The concern is not so much that the method described in this break is feasible on today's hardware, or even that this method will get cheaper and cheaper as hardware gets faster. The BIG concern is that this method provides insight in to the SHA-1 in general, and will be used by others to come up with more efficient breaks or more egregious flaws.
But that's not what seems to be happening. We've seen the same basic hack applied to multiple algorithms now, but we haven't seen the Md5 hacks improved for MD5.
-a
No crypto is powerful, or clever enough (yet!) to be completely unbreakable so its all down to making assumptions:
Wow, you made a statment like that without drawing 10 irrelevant replies about 1-time pads. I've never seen that before!
-a
The problem is the damn ads say NO LATE FEES...
/. want to take every reasonable statement to extremes.
Maybe the problem is that some people who read
-a
Despite the flames your post has drawn, the fact is there are off-the-shelf spyware programs that steal your banking info and let someone liquidate your account. That may not kill anyone, nut it's sure a pain in the ass.
-a
Let's say that this vulnerability reduces the average time needed to find a collision from 2^48 tries via the Birthday paradox (If this isn't a 96-bit hash, then I really need to get more sleep) to 2^32 tries. That's over 65,000 times faster, but you know why I'm not worried? That's still over 4,000,000,000 ISO files that the attacker would have to try before hitting on one that's got the wanted characteristics and the correct digest to boot,
You're misapplying the birthday paradox. The corrected statement is that the attacker would have to generate 4 million fake ISOs in order to have a high probability of generating a hash that collides with any one of 4 million real ISOs.
And that's *IF* your assumption was correct, which it most likely isn't. Cryptographic attacks aren't necessarily additive. You can't just assume that attack A reduces the key space by 10 bits and attack B reduces the key space by 20 bits so together they reduce the key space by 30 bits. It's not that simple.
-a
I thought the NSA already did this. I used to work for a security company, and I have vague memories of the NSA evaluating our product on behalf of the US government (i.e. to secure non-military traffic). We even had to drive off to a secure building in order to teleconference with them.
-a
With piracy resulting in only 4% loss, why are the studios making such a big deal?
Foresight?
-a
That is a good point, but it doesn't mean that the boot process can't be sped up quite a bit. It would especially be useful on laptops, or for people who like to save electricity by shutting down their computers when not in use.
It would probably be most useful for the Linux kernel developers themselves.
-a
"When you give it away without any cost, you make it worthless and cause people to think what we do is not legitimate."
I agree, and in fact I'm sure there are more than a few hookers out there that feel the exact same way.
Shh... I think this was intended as some kind of dig at OSS.
-a
Sure many of our neurons can self organize. We need that in order to learn. However, there are clearly some behaviours that can only be explained by instinct.
Some hardcoded area in our brains knows how to recognize faces, and regardless of whether we understand *how* it works, we can locate the area that does it.
-a
For describing an algorithm as being tantamount to thought, I think we have a mental obstacle in that we are unwilling to say that an algorithm is conscious unless we can't perceive that it is rule based. If an algorithm produces intelligent esults that couldn't be foreseen by examining the algorithms then philosophers will be more willing to accept it as intelligent.
I think the problem is not that we have an inadequate physical model of synapse formation. The problem is that the human brain is not a blank neural network. It is pre-trained by genetics, which gives us instincts and motivations and fears. Simulating instincts and also early childhood is likely to be the stumbling block in modern AI.
-a
It's not exactly difficult to add a random component into an AI algorithm.
-a
American: GM, Ford, Chrysler
Japanese: Toyota, Honda, Nissan
German: BMW, Mercedes, VW.
Your argument might hold some weight if carmaking was not aleady an international business. But it is. Defending your earlier statement by dividing the market into 3 groups of 3 smacks more of numerology than logic.
-a
I switched to Dvorak for awhile. I liked it in general (although it was a pain to remember where all the symbolic keys were).
The problem was that I often had to solve a problem at a co-worker's desk and switching between Dvorak and Qwerty was just too hard. The worst case of this was when I had to write some sample code (under time pressure) during a job interview. I didn't get the job (although probably not for that reason).
-a
the key question is, why was someone with obviously no grasp of proper application security design allowed to use identification numbers as passwords? any competent person in the field will tell you that they ARE NOT PASSWORDS and SHOULD NEVER BE USED AS PASSWORDS.
:-)
Heh... that should be MUST NOT be used as passwords.
The funny thing is that their security consultant is Scott Bradner, who came up with the MUST, SHOULD, etc. terminology for RFCs. He was also transport area director at the IETF (but not security area director).
The other funny thing is that his parents apparently gave him the middle name beginning with O, giving him the initials SOB.
-a
It's been said before, but mature industries tend towards three of something, such as GM-Ford-Chrysler.
That example is a little antiquated. So which are the three car makers now?
It seems to me that the number of players varies for every industry. After all, wasn't "one" the number of major players in the PC OS business?
-a
Kind of a mixed bag...
/.? Darest the pot call the kettle black?
Wordperfect: used initial success of Excel (not developed by Microsoft, BTW), created an integrated Office bundle (including Word) and started practically giving it away to businesses along with Windows.
Netscape: Umm, this is the case that got Microsoft convicted as an illegal monopoly, remember? If this case does not completely prove my allegations, none will.
Accusing MS of predatory pricing on
-a
Of course, this does pose a problem: currently, we're using up resources on a grand scale. And if our population growth continues as the average consumption of individuals go up, we may end up seeing a problem with a shortage of resources. This will cause prices for items to go up, which means that the increased salaries will have decreased worth
Yes, it is true. This is the major fallacy of the pro-globalization policies that are being thrust upon us.
(this is pretty much the case now in the US: you can live like a king in Beijing on $20,000 but in New York you'd barely be scraping by).
I don't think you can live like a king in Beijing for $20k. For one thing, prime Beijing real-estate is pretty expensive. Also, have you seen the way their kings used to live?
The flaws with outsourcing to China are two-fold:
1. Programmers are cheaper, but are generally far less qualified.
2. Everyone from partners to manufacturers and even the government is out to steal your technology.
I don't know the exact reason for #1. It's probably a combination of:
a) General lack of history with effective software development practices.
b) Programming is considered to be monkey work, whereas sales and marketing are held in high esteem.
c) Anyone with a higher education tends to emigrate. (Partly because of reason b.)
-a
I don't think most people think a car is like software - they think computers are like cars. They're both big expensive machines which everyone uses whether they want to or not, most people rely on them, and very few people know how to fix.
/. cliche is that when your car breaks down you don't have to take it back to the manufacturer to get it fixed - you just take it to your local mechanic. So why should closed source software companys be allowed to have a monopoly on support?
After that though the analogy breaks down a bit. Yes Mr. Gates it would be ludicrous for the government to tell you you have to buy your tires separately from your car (analogy he was hoisting when the whole IE Bundling thing went down) but at least tires can be removed from the car.
I think the standard
-a