josephscott

"Because the TLS handshake occurs before the HTTP connection begins, there can be problems if there are multiple websites hosted on the same server, at the same IP address."

This is why Server Name Indication ( SNI ) is so important. It allows multiple host names on a single IP address to support HTTPS.

Once again, IE on Windows XP is the biggest problem here. Windows XP systems simply must use something besides Internet Explorer ( Chrome or Firefox would be good ).

I worked for a placed that used the Reflections TCP/IP stack on Windows 3.x. I recall it working fairly well for that era.

You don't need to have very many application servers for this to become an issue. For instance, what if you host your site in multiple data centers? Each data center might only have a few servers, but any additional data layers that have to be kept in sync between the two is a non-trivial amount of additional complexity.

In addition to $_GET searching for $_POST and $_REQUEST are bad too. Could even through in $_COOKIE and $_SERVER for that matter.

This has me wondering if Google+ will eventually consume all of Blogger.

Got an email from VUDU about this, several things were stolen form their offices, includes hard drives:

"Our investigation thus far indicates that these hard drives contained customer information, including names, email addresses, postal addresses, phone numbers, account activity, dates of birth and the last four digits of some credit card numbers. It's important to note that the drives did NOT contain full credit card numbers, as we do not store that information. Additionally, please note if you have never set a password on the VUDU site and have only logged in through another site, your password was not on the hard drives.

While the stolen hard drives included VUDU account passwords, those passwords were encrypted. We believe it would be difficult to break the password encryption, but we can't rule out that possibility given the circumstances of this theft. So we think it's best to be proactive and ask that you be proactive as well."

As is the case in almost every password breach, it would be nice to know exactly how they "ecnrypted" the passwords.

Agreed, it would be nice to know they are using something reasonable, like bcrypt.

Their description would satisfied by a simple MD5 + salt, which wouldn't be very good for password storage.

Interesting map, zooming into Utah (where I live) shows that the local ISP Xmission is running 3 exit nodes. The map shows 4, but two of them have the same IP address.

jemalloc is another strong option -

http://www.mysqlperformanceblog.com/2012/07/05/impact-of-mem...

http://www.quora.com/Is-tcmalloc-stable-enough-for-productio...

"The poor state of passwords protection in web services: passwords are too often either stored in clear (these are the services that send you your password by email after hitting "I forgot my password"), or just hashed with a cryptographic hash function (like MD5 or SHA-1), which exposes users' passwords to efficient brute force cracking methods."

If you can't get people to use current crypto hashing techniques like bcrypt or scrypt why would coming up with another one help?

Of course it would be nice to see something with the work factor features of bcrypt that were more specifically resistant to GPU optimized crackers.

"so she could help make sure other children didn’t have to go through a similar traumatic experience."

If her goal is to help other children avoid going through this wouldn't the better problem to tackle be how to lower the number of divorces? Any divorce, no matter how "smooth" the process is is going to be painful for the kids.

I would feel better if I new how they handled passwords. Hopefully it is a hash and not encrypted. And hopefully that hash method is bcrypt (or something similarly painful to crack).

According to the changelog for parse_url that is no longer the case for 5.3.3 and up.

A logical first step would be to fix all of those functions in PHP that end up requiring the use of @. Once that is done then we could move forward with removing all @ use.

Seems odd to try and focus only on domestic migrations. In 1990 the population of California was 29.9M, in July 2011 it was 37.6M. The total population has continued to climb - https://www.google.com/publicdata/explore?ds=kf7tgg1uo9ude_&...

The net draw to California still seems to be in place.

I moved from California to Utah in 2007. The reason? My wife wanted to be closer to her family there and my job didn't care where I lived.

For news about updates an RSS/ATOM feed would be perfect. I don't want to signup for another email list and following another Twitter account is totally hit or miss on updates.

This is exactly the sort of thing reserved instances would be good for (when you know it is going to be in use 24/7).

A three year reserved instance would be significantly less than $60 per month. The upfront reserve price of $300 over 36 months comes out to $8.33/month. Throw in an approximate cost of $14/month for the use of the compute time, EBS, network traffic.

That brings your monthly cost to just under $23/month, for a grand total of nearly $830 over a 36 month period.

Agreed, VMS filesystem was the first thing that came to mind for me as well. Seems rather sad that in 2012 we don't have that as a standard feature like we did back then.

For the record, you don't have to be all that old to have used VMS's filesystem :-)

As mentioned, there is the opcode cache. I'm also thinking about FastCGI setups, where PHP is running the whole time, just waiting to execute code requests.

The small table comparing a large Wikipedia page is really the main point, a relative comparison of TTFB.

The mistake was is making a relative comparison on such super small numbers. If your TTFB is less than 2ms, then you are fine. You are better than fine.

If your TTFB is 1.5 seconds, then you are struggling.

In determining if you have a TTFB issue comparing the relative improvement of super small numbers isn't likely to help you much.

Unless the Internet involves using PHP, in which case he'd rather kill it :-)

I've worked at Automattic (a distributed company) for more than 5 years. The number one communication tool/method for most teams is IRC. We run our own internal IRC server, that logs everything in every channel. IRC is great for real time chat, when people are around at the same time.

Next most used communication method are internal P2s - http://p2theme.com/ - which is great for async communication. With people all over the world it is important to have a good async communication method.

Another reason both IRC and P2 are so important is that they have URLs for history. Anyone in the company can go back and read through the discussion.

The third communication method is Skype/Google Hangout. Many teams will have a regular (weekly is common) voice or video chat, generally less than an hour.

Looks like we had a couple of resources that weren't loading over HTTPS on the front page. Should be fixed now.