An old open-source tool called hypermail may be what you're looking for. It parses mbox files and produces HTML pages with the emails sorted by thread, author, subject, date, etc. http://hypermail-project.org/
The expert colleague actually got the *wrong* answer for xy_common. To me, that is the most interesting part of this experiment! What does that tell us? Maybe the "experts" could learn a thing or two from the novices, e.g., slow down a bit and verify results:)
It is pretty sad though how many of the apps don't encrypt the user data at all, or it's encrypted but the master password is stored in plaintext or is encrypted with a hard-coded key. Then there's many of them using strong crypto algs but not properly (e.g., what is the point of using PBKDF2 but with only 3 iterations?)
Mod parent up. The NT hash is essentially just a single MD4 of the Unicode password. (In the SAM file the hash is also obfuscated with the RID and encrypted with the syskey, but RID obfuscation is easily removed and the syskey by default is just stored in the registry and can be easily extracted.)
MS should have deprecated the NT hash like they did the LM hash, and replaced it with a salted iterative hash like PBKDF2.
(the kind of inconvenience they will hack around, possibly making you even more vulnerable)
Exactly. I worked around it and if I hadn't been able to I probably would have quit. The vpn client for windows enforced the company policy, but the vpn client for linux let me set up split tunelling the way I wanted. So I set up a linux router/firewall and never looked back.
Ok, my curioisty got the best of me. I altered the program to do 100 tests with a random stopping point each time. My results are:
Begins with 1: 20.57% Begins with 2: 17.69% Begins with 3: 15.35% Begins with 4: 13.26% Begins with 5: 10.86% Begins with 6: 8.0% Begins with 7: 6.14% Begins with 8: 5.1% Begins with 9: 3.7%
I'm still not seeing the 30% mentioned in the article, but it is a lot closer. Perhaps if I modified it to test a random # of primes instead of test up to a random # that would make a difference, but it doesn't seem like it would.
Exactly. It seems biased to me, but any arbitrary stopping place would be biased I suppose.
BTW, I posted an earlier comment where I considered all the prime below 1 million and it looks like this: Begins with 1: 12.21% Begins with 2: 11.64% Begins with 3: 11.41% Begins with 4: 11.14% Begins with 5: 10.97% Begins with 6: 10.77% Begins with 7: 10.74% Begins with 8: 10.60% Begins with 9: 10.48%
Here's all primes below 2 million: Begins with 1: 53.72% Begins with 2: 6.13% Begins with 3: 6.1% Begins with 4: 5.87% Begins with 5: 5.78% Begins with 6: 5.67% Begins with 7: 5.66% Begins with 8: 5.59% Begins with 9: 5.52%
And here's all primes below 3 million: Begins with 1: 36.90% Begins with 2: 35.52% Begins with 3: 4.13% Begins with 4: 4.3% Begins with 5: 3.97% Begins with 6: 3.90% Begins with 7: 3.89% Begins with 8: 3.84% Begins with 9: 3.79%
Perhaps an unbiased "test" would be one where you average the results of several tests, picking a random number each time as the stopping place (either the upper limit or the # of primes, probably doesn't matter).
I wrote a little test program to test all the primes below 1 million and it looks like this:
Begins with 1: 12.21% Begins with 2: 11.64% Begins with 3: 11.41% Begins with 4: 11.14% Begins with 5: 10.97% Begins with 6: 10.77% Begins with 7: 10.74% Begins with 8: 10.60% Begins with 9: 10.48%
So I want to know, where did they get 30% from? Maybe they meant to say 13%.
Oh, I understand now. After reading some other posts, I now understand that "right" is a special prefix you can use to force it to use an "alternative timescale where time_t includes leap seconds."
But that is not the default behavior for POSIX. And as mentioned below, "I've never seen a linux distro that enabled this by default."
You answered your own question: "buy a domain and using Google Apps on it". Who cares if it "isn't actually intended for home users"? If it works for you, then it is for you.
I use it for my personal domain and it was extremely easy to set up and works great for me.
It seems to imply that Storm is being removed by other malicious software, not the efforts of researchers. When the article says "new malicious software removal tools", I think it refers to something like Microsoft's Malicious Software Removal Tool, not other malicious software.
Umm, just write portable code that doesn't depend on int, long, etc. being a specific length.
If you need specific sizes, create a common header which defines types like int16, int32, int64. Then porting to another system involves changing just the one header. In C99 there is a header called stdint.h which does exactly that.
CMake is easy too.
An old open-source tool called hypermail may be what you're looking for. It parses mbox files and produces HTML pages with the emails sorted by thread, author, subject, date, etc. http://hypermail-project.org/
The expert colleague actually got the *wrong* answer for xy_common. To me, that is the most interesting part of this experiment! What does that tell us? Maybe the "experts" could learn a thing or two from the novices, e.g., slow down a bit and verify results :)
It is pretty sad though how many of the apps don't encrypt the user data at all, or it's encrypted but the master password is stored in plaintext or is encrypted with a hard-coded key. Then there's many of them using strong crypto algs but not properly (e.g., what is the point of using PBKDF2 but with only 3 iterations?)
Mod parent up. The NT hash is essentially just a single MD4 of the Unicode password. (In the SAM file the hash is also obfuscated with the RID and encrypted with the syskey, but RID obfuscation is easily removed and the syskey by default is just stored in the registry and can be easily extracted.) MS should have deprecated the NT hash like they did the LM hash, and replaced it with a salted iterative hash like PBKDF2.
Do I really want my CPU to overload while navigating the web?
Yeah, but we're talking about digital displays not camera lenses. The term resolution has always been used to mean pixel dimensions.
If you just need debugging, try cgdb. It's very lightweight.
The OST file format is pretty much identical to PST.
(the kind of inconvenience they will hack around, possibly making you even more vulnerable)
Exactly. I worked around it and if I hadn't been able to I probably would have quit. The vpn client for windows enforced the company policy, but the vpn client for linux let me set up split tunelling the way I wanted. So I set up a linux router/firewall and never looked back.
I blogged about it last year: http://hellewell.homeip.net/phillip/blogs/index.php?entry=entry080509-170319
Ok, my curioisty got the best of me. I altered the program to do 100 tests with a random stopping point each time. My results are:
Begins with 1: 20.57%
Begins with 2: 17.69%
Begins with 3: 15.35%
Begins with 4: 13.26%
Begins with 5: 10.86%
Begins with 6: 8.0%
Begins with 7: 6.14%
Begins with 8: 5.1%
Begins with 9: 3.7%
I'm still not seeing the 30% mentioned in the article, but it is a lot closer. Perhaps if I modified it to test a random # of primes instead of test up to a random # that would make a difference, but it doesn't seem like it would.
Exactly. It seems biased to me, but any arbitrary stopping place would be biased I suppose.
BTW, I posted an earlier comment where I considered all the prime below 1 million and it looks like this:
Begins with 1: 12.21%
Begins with 2: 11.64%
Begins with 3: 11.41%
Begins with 4: 11.14%
Begins with 5: 10.97%
Begins with 6: 10.77%
Begins with 7: 10.74%
Begins with 8: 10.60%
Begins with 9: 10.48%
Here's all primes below 2 million:
Begins with 1: 53.72%
Begins with 2: 6.13%
Begins with 3: 6.1%
Begins with 4: 5.87%
Begins with 5: 5.78%
Begins with 6: 5.67%
Begins with 7: 5.66%
Begins with 8: 5.59%
Begins with 9: 5.52%
And here's all primes below 3 million:
Begins with 1: 36.90%
Begins with 2: 35.52%
Begins with 3: 4.13%
Begins with 4: 4.3%
Begins with 5: 3.97%
Begins with 6: 3.90%
Begins with 7: 3.89%
Begins with 8: 3.84%
Begins with 9: 3.79%
Perhaps an unbiased "test" would be one where you average the results of several tests, picking a random number each time as the stopping place (either the upper limit or the # of primes, probably doesn't matter).
P.S. Here's my source code (uses openssl library): http://codepad.org/0DfZ8uOG
I wrote a little test program to test all the primes below 1 million and it looks like this:
Begins with 1: 12.21%
Begins with 2: 11.64%
Begins with 3: 11.41%
Begins with 4: 11.14%
Begins with 5: 10.97%
Begins with 6: 10.77%
Begins with 7: 10.74%
Begins with 8: 10.60%
Begins with 9: 10.48%
So I want to know, where did they get 30% from? Maybe they meant to say 13%.
Oh, I understand now. After reading some other posts, I now understand that "right" is a special prefix you can use to force it to use an "alternative timescale where time_t includes leap seconds."
But that is not the default behavior for POSIX. And as mentioned below, "I've never seen a linux distro that enabled this by default."
But it doesn't do that with my timezone:
TZ="US/Mountain" date -d @1230793199
Wed Dec 31 23:59:59 MST 2008
TZ="US/Mountain" date -d @1230793200
Thu Jan 1 00:00:00 MST 2009
What's the deal?
This was me. Posted anonymous by accident.
Exactly. Couldn't have said it better myself.
Sorry, UNIX time is exactly 86400 seconds per day.
Exactly. Mod parent up. Mod gparent down.
date -u -d @1230767999
Wed Dec 31 23:59:59 UTC 2008
date -u -d @1230768000
Thu Jan 1 00:00:00 UTC 2009
What happened to the leap second? It was completely ignored, yep.
You answered your own question: "buy a domain and using Google Apps on it". Who cares if it "isn't actually intended for home users"? If it works for you, then it is for you.
I use it for my personal domain and it was extremely easy to set up and works great for me.
it's cstring not string for the c++ header
http://www.giantitp.com/comics/oots0536.html
Umm, just write portable code that doesn't depend on int, long, etc. being a specific length.
If you need specific sizes, create a common header which defines types like int16, int32, int64. Then porting to another system involves changing just the one header. In C99 there is a header called stdint.h which does exactly that.