If every different game or mod I try to run under Steam crashes, I think it is fair to assume it is a problem with Steam. Steam works fine FOR YOU, but don't kid yourself, NOT EVERYONE IS SO LUCKY.
Thank you for agreeing with me, even if you didn't think you were. I never said VB was better than C#. If you would recall, this is a discussion attached to the story titled "Searching for the Best Scripting Language."
Should you want to develop a middleweight app, then C#'s syntax is far more suitable. It is, however, an atrocious scripting language.
I repeat my point: If you want do some lightweight GUI app in a quick, simple, maintainable fashion, then VB is a better choice than C#.
I am a big fan of Python, and I think this 'search' represented Python pretty well. It isn't great at hacking out short scripts, so it doesn't deserve to win this pointed competition, but its verbose yet pretty syntax makes solid scripts and maintainable, extendable code a joy to program.
The last time I tried to run Steam? A few days ago. It would crash horribly after half a minute. The sound didn't work. It took an age to download, and it still takes literally hours to update. I do have an adequate internet connection. What Steam wants is an extremely powerful internet connection
This would be grave mistake for Microsoft. If they did, Linux could gain even more of a performance advantage on AMD hardware, which would further damage their sales. I suspect Microsoft will once again take the selfish option and give the best performance possible.
xvid is indeed meant to be DivX spelt backwards, a fact that is more noticeable if you actually use the shift key on your keyboard. xvid is normally represented as XviD.
Look, I understand that words can take on new meanings based on popular understanding of their meaning. I still despise the use of the term 'social engineering' for things like this.
Social engineering is the practical field of changing a society or its mores through political means. It is *not* what Kevin Mitnik used the term for, which is should be termed acting, lying, or confidence art. The use of the term seems to stem form a strange desire to geek-romanticise the art of 'how to lie convincingly.'
The continued misuse of the term is slightly ironic; The same people who fight against the popular-use meaning of the word 'hacker' are attempting to change the meaning for 'social engineering' to be what the person to whom the word 'hacker' was most obviously applied, used that phrase for.
As usual, my anti-mismoderation statement must be "I am no troll, and this is not intended to be a flame or flamebait, but rather my considered opinion."
Yeah, no shit, but you didn't RTFA, and have no idea what you are talking about, dou you? The T&L functions are totaly useless by themselves. In all the cards that have T&L but no programmable shaders (eg Geforce, geforce2) the rendering pipeline is only partly exposed to the developer, and thus useless for anything but drawing 3d graphics. With programmable shaders, the complete vertex transform process is accesible, and that is what this paper talks about using.
Are you saying that users do regularly select passwords with numbers and capitals in them?
I have been ignoring your repeated suggestion about checking the passwords in the hope you would RTFA. What you suggest is standard practice for all good SysAdmins, and the whole purpose of this article was to provide additional too-common passwords for a SysAdmin.
You are once again stating the obvious. I agree with you entirely on that matter, as I have from the beginning. However, once again I submit to you that the only way to get most users to include numbers in their passwords at all is to force the inclusion of at least one number. The password that has at least one number is more secure than the password that will not have any numbers.
I must apollogise for calling you an idiot. Statistics can often be counter-intuitive (as in the case of the Monty Hall problem.) You are wrong, but I am sorry for insulting you.
Of course forcing users to have ONLY TWO chars (101*101) is going to produce less passwords than allowing users to have EITHER one or two chars (101 * 101 + 101).
That means absolutely nothing for the issue at hand, as nobody would limit their users to a two-char password. When the number of chars scale up, the number of passwords also scales up, but geometrically, not linearly.
Thus, even limiting the number of chars to 9 ONLY is still 25 times better than allowing the choice of any password from 1 to 8 chars.
Your gasp of probablity is very weak. If half the entries are removed from a list, the chance of ANY PARTICULAR PASSWORD, be it assigned X, Y, Z or any other variable name, is also halved. We could carry your reasoning to its illogical conclusion: Given that any password may appear on a cracker's dictionary, and given that the cracker could prune his list to contain only that password, that cracker can and will defeat any password with only one attempt.
Then with your password Y, in a perfect world, you would save some time over an identical test with no non-alpha requirement. But as this is NOT a perfect world, the test is not identical, as people pick fewer chars. Thus, you in fact save no time, because you now have to check passwords far longer than you would have otherwise checked.
Users that pick stupid passwords with no constraints may be the same users that pick stupid passwords with some alpha shoved in it because the software insists on it, BUT SHOVING THE EXTRA NUMBER IN MEANS THAT THE CRACKER NEEDS TO CHECK FAR MORE PASSWORDS.
Once again, look at the example you gave at the start, and look at the numbers. Shoving the number in increased the number of passwords from: (26^6 + 26^7 + 26^8 + 26^9) = 5646671469504 to: (36**6 + 36**7 + 36**8 + 36**9) - (26^6 + 26^7 + 26^8 + 26^9) = 98814936052800
Once again I ask, how can that be easier to crack?
Can you give me even one example where adding a number to a password of length greater than two decreases the number of possible passwords?
Want some more numbers? Assuming that 18 days is time it takes to test the entire space that was limited to a 4 or 5-byte (8 bit) password, it would have taken him at most 23 seconds to find the unrestricted, 3 byte password that the unrestrected user had chosen.
Not at all! You have reduced the amount of time to test a dictionary by 5/6ths, but you have also decreased the chance of a match by the same amount, and increased the length of an already-long brute force attack fo 3000 times.
And this is ignoring the benificial effect that making the end users THINK about their password has.
You are still not understanding the basic premise of this topic. If you do not limit the number of chars in a password, almost all your passwords will be six or less chars.
If you do limit as per your suggestion, you will increase the number of passwords by over three hundred thousand times. How does this make the passwords LESS secure?
Slashdot Mirror
Why can't people like you admit when you are wrong? Yes, good idea, BUT YOU STILL WOULDN'T CHOOSE C#, which is what this thread is about.
If every different game or mod I try to run under Steam crashes, I think it is fair to assume it is a problem with Steam. Steam works fine FOR YOU, but don't kid yourself, NOT EVERYONE IS SO LUCKY.
Thank you for agreeing with me, even if you didn't think you were. I never said VB was better than C#. If you would recall, this is a discussion attached to the story titled "Searching for the Best Scripting Language."
Should you want to develop a middleweight app, then C#'s syntax is far more suitable. It is, however, an atrocious scripting language.
I repeat my point: If you want do some lightweight GUI app in a quick, simple, maintainable fashion, then VB is a better choice than C#.
On the contrary, I am a big fan of Python. However, since Glade isn't actually an official part of Python, it kind of doesn't belong in this argument.
Even if it did, I still contend that it is much faster to write a small app (especially a database frontend) in VB.
Yeah, but for the few lines of code you need to write for the app, VB is easier than C# by several degrees.
I am a big fan of Python, and I think this 'search' represented Python pretty well. It isn't great at hacking out short scripts, so it doesn't deserve to win this pointed competition, but its verbose yet pretty syntax makes solid scripts and maintainable, extendable code a joy to program.
If you are talking about VB.NET, then you are right. But the real VB, v3 and up, remains the pinnacle of GUI RAD.
> (Hint: sort it first, and flip the last two elements)
:)
hint for the other guy: Pick a dataset size of one element
The last time I tried to run Steam? A few days ago. It would crash horribly after half a minute. The sound didn't work. It took an age to download, and it still takes literally hours to update. I do have an adequate internet connection. What Steam wants is an extremely powerful internet connection
This would be grave mistake for Microsoft. If they did, Linux could gain even more of a performance advantage on AMD hardware, which would further damage their sales. I suspect Microsoft will once again take the selfish option and give the best performance possible.
xvid is indeed meant to be DivX spelt backwards, a fact that is more noticeable if you actually use the shift key on your keyboard. xvid is normally represented as XviD.
Here is a mirror of the site:
"XviD owned ?? oohhhh yeahhh BloodBR ownz XviD - sorry admin leak@hackermail.com"
Hehehe... XviD goy hacked...
Look, I understand that words can take on new meanings based on popular understanding of their meaning. I still despise the use of the term 'social engineering' for things like this.
Social engineering is the practical field of changing a society or its mores through political means. It is *not* what Kevin Mitnik used the term for, which is should be termed acting, lying, or confidence art. The use of the term seems to stem form a strange desire to geek-romanticise the art of 'how to lie convincingly.'
The continued misuse of the term is slightly ironic; The same people who fight against the popular-use meaning of the word 'hacker' are attempting to change the meaning for 'social engineering' to be what the person to whom the word 'hacker' was most obviously applied, used that phrase for.
As usual, my anti-mismoderation statement must be "I am no troll, and this is not intended to be a flame or flamebait, but rather my considered opinion."
If you prefer you language colourful, try f*ck f*ck.
Yeah, no shit, but you didn't RTFA, and have no idea what you are talking about, dou you? The T&L functions are totaly useless by themselves. In all the cards that have T&L but no programmable shaders (eg Geforce, geforce2) the rendering pipeline is only partly exposed to the developer, and thus useless for anything but drawing 3d graphics. With programmable shaders, the complete vertex transform process is accesible, and that is what this paper talks about using.
Surely the real untapped goldmines are the shaders?
What's wrong with "I've"?
Step 3 breaks out of the loop when there are no more changes the programmer can make.
Are you saying that users do regularly select passwords with numbers and capitals in them?
I have been ignoring your repeated suggestion about checking the passwords in the hope you would RTFA. What you suggest is standard practice for all good SysAdmins, and the whole purpose of this article was to provide additional too-common passwords for a SysAdmin.
You are once again stating the obvious. I agree with you entirely on that matter, as I have from the beginning. However, once again I submit to you that the only way to get most users to include numbers in their passwords at all is to force the inclusion of at least one number. The password that has at least one number is more secure than the password that will not have any numbers.
I must apollogise for calling you an idiot. Statistics can often be counter-intuitive (as in the case of the Monty Hall problem.) You are wrong, but I am sorry for insulting you.
I am no troll, but you sir, remain an idiot.
Of course forcing users to have ONLY TWO chars (101*101) is going to produce less passwords than allowing users to have EITHER one or two chars (101 * 101 + 101).
That means absolutely nothing for the issue at hand, as nobody would limit their users to a two-char password. When the number of chars scale up, the number of passwords also scales up, but geometrically, not linearly.
Thus, even limiting the number of chars to 9 ONLY is still 25 times better than allowing the choice of any password from 1 to 8 chars.
Your gasp of probablity is very weak. If half the entries are removed from a list, the chance of ANY PARTICULAR PASSWORD, be it assigned X, Y, Z or any other variable name, is also halved. We could carry your reasoning to its illogical conclusion: Given that any password may appear on a cracker's dictionary, and given that the cracker could prune his list to contain only that password, that cracker can and will defeat any password with only one attempt.
Then with your password Y, in a perfect world, you would save some time over an identical test with no non-alpha requirement. But as this is NOT a perfect world, the test is not identical, as people pick fewer chars. Thus, you in fact save no time, because you now have to check passwords far longer than you would have otherwise checked.
Users that pick stupid passwords with no constraints may be the same users that pick stupid passwords with some alpha shoved in it because the software insists on it, BUT SHOVING THE EXTRA NUMBER IN MEANS THAT THE CRACKER NEEDS TO CHECK FAR MORE PASSWORDS.
Once again, look at the example you gave at the start, and look at the numbers. Shoving the number in increased the number of passwords from:
(26^6 + 26^7 + 26^8 + 26^9)
= 5646671469504
to:
(36**6 + 36**7 + 36**8 + 36**9) - (26^6 + 26^7 + 26^8 + 26^9)
= 98814936052800
Once again I ask, how can that be easier to crack?
Can you give me even one example where adding a number to a password of length greater than two decreases the number of possible passwords?
Want some more numbers? Assuming that 18 days is time it takes to test the entire space that was limited to a 4 or 5-byte (8 bit) password, it would have taken him at most 23 seconds to find the unrestricted, 3 byte password that the unrestrected user had chosen.
Not at all! You have reduced the amount of time to test a dictionary by 5/6ths, but you have also decreased the chance of a match by the same amount, and increased the length of an already-long brute force attack fo 3000 times.
And this is ignoring the benificial effect that making the end users THINK about their password has.
You are still not understanding the basic premise of this topic. If you do not limit the number of chars in a password, almost all your passwords will be six or less chars.
If you do limit as per your suggestion, you will increase the number of passwords by over three hundred thousand times. How does this make the passwords LESS secure?