Oh, nonsense. If you go into McDonalds or Burger King or Wendy's, you will always find a 99 cent simple hamburger or cheeseburger on the menu. It's a pretty small portion representing a very limited number of calories. You can also get small helpings of french fries that are pretty parsimonious in amount, if not usually in price. Yeah, the super triple ultimo burger with collossal oveflowing fries is ridiculously huge, but that's not the only thing available.
Exactly. Pure, literally unbridled democracy is just a form of tyranny. If a hundred million voters passing direct judgement on every item of business in the government never unjustly oppress some minority, it would be not only pure luck, but a denial of human nature. A constitutional republic is one way of limiting the democratic power of The People to protect individual persons.
Alone, alternating caps adds next to no security. It is one of a number of well-known predictable ideas which are cheap to test for, so the attacker will try them. It only takes three times as long to test the root plus both series of alternating caps as it does to test just the all lower case root. Using leet speak (sorry, 133+ speak) is not of very much use for the same reason.
Truly random upper case characters and digits thrown into the password, in NON-OBVIOUS PLACES, offers FAR more security.
The number of permutations of four lower case letters, for example 'fish', is 26*26*26*26, or 456,976. Adding use of all caps, e.g. FISH' and capitalizing the first letter, e.g. 'Fish', only TRIPLES the number of cases to test: a total of 1,370,928. Probably not worth it. Adding the two alternating caps cases, e.g. 'FiSh' and 'fIsH', only quintuples the number of cases to test: a total of 2,284,880. A big waste. Using 5 lower case letters alone instead of 4 would get you far more benefit than these tricks - 11,881,376 cases.
But if you throw in truly random upper case letters and digits, even one or two of each in non-obvious places, the number of cases to test for even a 4 place password becomes 14,776,336, and for 5 characters, 916,132,832. Now we're getting a truly useful benefit. Adding the set of ASCII symbols helps even more, but makes it a lot harder to type.
Obviously the above assumes you eliminate dictionary attack, so you wouldn't use 'fish' as the root. Maybe you would use 'tqod'. That's a lot better than 'fish', but still not very high grade. The important thing is that you don't think changing it to 'Tqod' or 'TqOd' is going to buy you anything significant. But 't7qOD' would be a lot better.
Your use of symbols, avoidance of dictionary words and syllables, and separation of the digits is good. Putting the symbols at the front and back is less beneficial. The alternating caps wouldn't normally do much good at all, but combined with your other techniques they're not really in alternating positions. I'd say you've got a pretty damn good system.
The -15 tells you the patch level. 2.2.15-15.el6.x86_64 was issued this month. As long as Redhat supports RHEL6, and that will be for a goodly number of years more, they will issue security and other patches. For example, their kernel is presently 2.6.32-220.2.1.el6.x86_64, but they track and backport not only the latest security patches but also a lot of hardware support and new feature improvements.
Oh come now. How can anything be easier than every place on earth having exactly the same time. You say, "I'll call you at 1900 on Saturday after you get back to France" rather than "I'll call you at 7pm on Saturday after you get back to France - let's see - that would be... uh... um... ah... what's that your time?" And no constant resetting your watch when traveling.
"how many mm is my 5/8" head bolt?" - 15.875. "how many meters are between my 16" on center wall studs?" - 0.4064 "Why would all my roughly 1 mile apart main streets now be stuck at 2.4ish km?" - for the same reason all your streets which are now about 1.25ish miles apart will now be a nice round 2 km apart. Any other pointless questions I can help you with? Just how do you think every other country in the world, with a handful of exceptions, converted to metric? By JUST DOING IT, that's how. Funny. It didn't hurt any of them, or overtax people's brains there.
Just think how superior anyone with a halfway working sense of math is going to feel for a few years until everyone gets used to the new way.
Thanks; found it. Bummer. Is there ANYTHING that is not optional in C/C++? OK, that's rhetorical.
Just to clarify, it's not that the implementation has an "int" that is 64 bits; it's that it has SOME integer type that is 64 bits: maybe int, maybe long, maybe long long. So an oddball machine that has a 36 bit word size or something may well not have int64_t. That case is so far off my radar I tend to ignore it. It certainly doesn't apply to any PC I can think of. Everything I, and probably 99.9% of readers of this story, come near is going to have it.
But the following types ARE REQUIRED in a C99 compliant compiler: [u]int_least[8,16,32,64]_t. So if you use int_least64_t instead of int64_t in the example, then it has to compile and it has to work. You might get a 64 bit variable, you might possibly get 72 bits, conceivably you could get 91 bits or 10,013 bits, but it is going to be able to manipulate any 64 bit signed quantity, taking care with the sign extension.
Very good to know all the same; can't imagine how much reading I would have had to do to find that. You can actually put spaces around PRId64 without changing the printout if you think it looks more readable, but you do still need the % - e.g., "printf("There are %" PRId64 " widgets\n", n);"
I'm still not finding anything to accomplish a parallel effect for integer constants, though.
I thought I made that clear with my source. The markup was screwed up in my first post, but you can see the includes in my followup. But really, this is all irrelevant to whether C90 supported 64 bit integers without relying on extensions or user code. Both <stdint.h> and <cstdint> are in the C++11 standard. BTW, FWIW, I believe there is still a weak point in all the C and C++ standards. To the best of my knowledge, the integer constant suffixes such as LL (and the %lld specifier in printf) parallel the "long long" data type, but "long long" is not guaranteed to be the same as int64_t. Heck, even L and %ld are only guaranteed to be "long" data type, not necessarily 32 bits. I'm not prepared to claim that I have perfectly absorbed all 1356 pages of the C++11 standard though.
Anyway, from ISO/IEC 14882, Third Edition, 2011-09-01, Appendix D.5 C standard library headers:
"For compatibility with the C standard library and the C Unicode TR, the C++ standard library provides the 25 C headers, as shown in Table 154.
OK, wise guy. The following works in either unextended C99 or unextended C++11. So now put up or shut up. Unextended C90. Can't be done. Never ask a question of a witness you don't know the answer to, and never challenge opposing counsel to prove something.
#include #include int main(int argc, char *argv[]) {
int64_t a = 50000000000LL;
int64_t b = 100000000000LL;
int64_t c = 0;
No, no, no. That's not the issue. C++ can automatically call any C code using 'extern "C"'. The issue is, how will C++ do *COMPILING* C source in C++ mode. C++ is not a true superset of C, so C is not a true subset of C++. Anything that makes them closer to being a super/sub set pair is a Good Thing.
The fuck they don't. If, I mean WHEN, they want an authoritative answer to some question about the language, they need the standard. Anything else is just an opinion.
I can't believe nobody has mentioned http://webkeepers.com/. You can get in for as little as $6.95 a month, and for $19.95 a month you get an unmatched 250GB of disk and 1GB of guaranteed RAM. They have been excellent for me.
Slashdot Mirror
Oh, nonsense. If you go into McDonalds or Burger King or Wendy's, you will always find a 99 cent simple hamburger or cheeseburger on the menu. It's a pretty small portion representing a very limited number of calories. You can also get small helpings of french fries that are pretty parsimonious in amount, if not usually in price. Yeah, the super triple ultimo burger with collossal oveflowing fries is ridiculously huge, but that's not the only thing available.
Exactly. Pure, literally unbridled democracy is just a form of tyranny. If a hundred million voters passing direct judgement on every item of business in the government never unjustly oppress some minority, it would be not only pure luck, but a denial of human nature. A constitutional republic is one way of limiting the democratic power of The People to protect individual persons.
The court is corrupt on the face of this decision. Impeach the judges responsible.
I don't think it makes any difference in principle what the distro is, apart from rolling releases. For example debian squeeze:
root@testvm:~# dpkg-query -p apache2 | grep Version
Version: 2.2.16-6+squeeze4
I'd be surprised if that did not include the latest security patches.
Yes, I think "pretty damn good system" makes it pretty clear I like it.
The rest is a completely general critique of a lot of not so good ideas that are found in this topic in general.
Alone, alternating caps adds next to no security. It is one of a number of well-known predictable ideas which are cheap to test for, so the attacker will try them. It only takes three times as long to test the root plus both series of alternating caps as it does to test just the all lower case root. Using leet speak (sorry, 133+ speak) is not of very much use for the same reason.
Truly random upper case characters and digits thrown into the password, in NON-OBVIOUS PLACES, offers FAR more security.
The number of permutations of four lower case letters, for example 'fish', is 26*26*26*26, or 456,976. Adding use of all caps, e.g. FISH' and capitalizing the first letter, e.g. 'Fish', only TRIPLES the number of cases to test: a total of 1,370,928. Probably not worth it. Adding the two alternating caps cases, e.g. 'FiSh' and 'fIsH', only quintuples the number of cases to test: a total of 2,284,880. A big waste. Using 5 lower case letters alone instead of 4 would get you far more benefit than these tricks - 11,881,376 cases.
But if you throw in truly random upper case letters and digits, even one or two of each in non-obvious places, the number of cases to test for even a 4 place password becomes 14,776,336, and for 5 characters, 916,132,832. Now we're getting a truly useful benefit. Adding the set of ASCII symbols helps even more, but makes it a lot harder to type.
Obviously the above assumes you eliminate dictionary attack, so you wouldn't use 'fish' as the root. Maybe you would use 'tqod'. That's a lot better than 'fish', but still not very high grade. The important thing is that you don't think changing it to 'Tqod' or 'TqOd' is going to buy you anything significant. But 't7qOD' would be a lot better.
Your use of symbols, avoidance of dictionary words and syllables, and separation of the digits is good. Putting the symbols at the front and back is less beneficial. The alternating caps wouldn't normally do much good at all, but combined with your other techniques they're not really in alternating positions. I'd say you've got a pretty damn good system.
They did, and they are.
Bzzzt. Thank you for playing. The 2.2.15 doesn't tell you the patch level. Here's from a completely up to date RHEL6 system:
[fnj@baldur ~]$ rpm -qa | grep httpd
httpd-tools-2.2.15-15.el6.x86_64
httpd-2.2.15-15.el6.x86_64
The -15 tells you the patch level. 2.2.15-15.el6.x86_64 was issued this month. As long as Redhat supports RHEL6, and that will be for a goodly number of years more, they will issue security and other patches. For example, their kernel is presently 2.6.32-220.2.1.el6.x86_64, but they track and backport not only the latest security patches but also a lot of hardware support and new feature improvements.
It would be a damn good remedy.
Guess he's got company.
Oh come now. How can anything be easier than every place on earth having exactly the same time. You say, "I'll call you at 1900 on Saturday after you get back to France" rather than "I'll call you at 7pm on Saturday after you get back to France - let's see - that would be ... uh ... um ... ah ... what's that your time?" And no constant resetting your watch when traveling.
So if I'm paid on salary every week, I will get an extra week's pay once every 5-6 years? I can dig this new system.
"how many mm is my 5/8" head bolt?" - 15.875.
"how many meters are between my 16" on center wall studs?" - 0.4064
"Why would all my roughly 1 mile apart main streets now be stuck at 2.4ish km?" - for the same reason all your streets which are now about 1.25ish miles apart will now be a nice round 2 km apart.
Any other pointless questions I can help you with?
Just how do you think every other country in the world, with a handful of exceptions, converted to metric? By JUST DOING IT, that's how. Funny. It didn't hurt any of them, or overtax people's brains there.
Just think how superior anyone with a halfway working sense of math is going to feel for a few years until everyone gets used to the new way.
Are you bloody insane?
AC is a doofus. Speaker cables do not need shielding. The idea is ludicrous.
Thanks; found it. Bummer. Is there ANYTHING that is not optional in C/C++? OK, that's rhetorical.
Just to clarify, it's not that the implementation has an "int" that is 64 bits; it's that it has SOME integer type that is 64 bits: maybe int, maybe long, maybe long long. So an oddball machine that has a 36 bit word size or something may well not have int64_t. That case is so far off my radar I tend to ignore it. It certainly doesn't apply to any PC I can think of. Everything I, and probably 99.9% of readers of this story, come near is going to have it.
But the following types ARE REQUIRED in a C99 compliant compiler: [u]int_least[8,16,32,64]_t. So if you use int_least64_t instead of int64_t in the example, then it has to compile and it has to work. You might get a 64 bit variable, you might possibly get 72 bits, conceivably you could get 91 bits or 10,013 bits, but it is going to be able to manipulate any 64 bit signed quantity, taking care with the sign extension.
Very good to know all the same; can't imagine how much reading I would have had to do to find that. You can actually put spaces around PRId64 without changing the printout if you think it looks more readable, but you do still need the % - e.g., "printf("There are %" PRId64 " widgets\n", n);"
I'm still not finding anything to accomplish a parallel effect for integer constants, though.
I thought I made that clear with my source. The markup was screwed up in my first post, but you can see the includes in my followup. But really, this is all irrelevant to whether C90 supported 64 bit integers without relying on extensions or user code. Both <stdint.h> and <cstdint> are in the C++11 standard. BTW, FWIW, I believe there is still a weak point in all the C and C++ standards. To the best of my knowledge, the integer constant suffixes such as LL (and the %lld specifier in printf) parallel the "long long" data type, but "long long" is not guaranteed to be the same as int64_t. Heck, even L and %ld are only guaranteed to be "long" data type, not necessarily 32 bits. I'm not prepared to claim that I have perfectly absorbed all 1356 pages of the C++11 standard though.
Anyway, from ISO/IEC 14882, Third Edition, 2011-09-01, Appendix D.5 C standard library headers:
"For compatibility with the C standard library and the C Unicode TR, the C++ standard library provides the 25 C headers, as shown in Table 154.
"Table 154 - C headers: ... ..."
Fucking markup. Here's a version you can read.
#include <stdio.h>
#include <stdint.h>
int main(int argc, char *argv[])
{
int64_t a = 50000000000LL;
int64_t b = 100000000000LL;
int64_t c = 0;
c = a + b;
printf("%lld\n", c);
return 0;
}
OK, wise guy. The following works in either unextended C99 or unextended C++11. So now put up or shut up. Unextended C90. Can't be done. Never ask a question of a witness you don't know the answer to, and never challenge opposing counsel to prove something.
#include
#include
int main(int argc, char *argv[])
{
int64_t a = 50000000000LL;
int64_t b = 100000000000LL;
int64_t c = 0;
c = a + b;
printf("%lld\n", c);
return 0;
}
One man's incoherent mess is another man's versatility.
It's OK. C++ is the MOST able to call C of any language. Parent was confused.
No, no, no. That's not the issue. C++ can automatically call any C code using 'extern "C"'. The issue is, how will C++ do *COMPILING* C source in C++ mode. C++ is not a true superset of C, so C is not a true subset of C++. Anything that makes them closer to being a super/sub set pair is a Good Thing.
The fuck they don't. If, I mean WHEN, they want an authoritative answer to some question about the language, they need the standard. Anything else is just an opinion.
I can't believe nobody has mentioned http://webkeepers.com/. You can get in for as little as $6.95 a month, and for $19.95 a month you get an unmatched 250GB of disk and 1GB of guaranteed RAM. They have been excellent for me.