Right, but this is giving you active users. I think you underestimate how big Facebook really is.

For example, take the following info. This shows that 44% of the population of the UK have an active Facebook account. Keep in mind this isn't internet active people, but total population. If you counted internet active, you would have 58% instead (keeping in mind that internetworldstats.com is a bit old compared to the Facebook data).

This is your problem. The 400 million number is monthly active users (just like most web companies quote). These are at least semi-active accounts, they have logged in and been active at least once in the last month. If someone signs up and then never uses it again, or stops using it, then they will not be counted in the 400m value.

RSS is pull technology, so the interested server (ie Google) needs to keep polling you asking if you have new content.

PubSubHubbub is push technology. So when you make a change, you submit it to a hub which in turn knows the interested parties that have asked to know about your site and then distributes it to them.

So it is more efficient since there isn't a constant polling and it is faster since there isn't a poll lag.

We do have access to it now, thanks. However, it doesn't allow us to get a fix out prior to the disclosure. I have no problem with him selling a scanner for the exploit, I am totally fine with him using that to his monetary advantage.

Keep in mind it is his customers (assuming they are not black hat) he is hurting as well, as the ones that want to scan for the exploit most likely would like to fix the exploit rather than just totally disable the product.

The problem is that he isn't contacting the vendors in this case. He said that in the past he has tried contacting them (in the general sense, not these vendors specifically) and some of them didn't reply so from now on, all vendors are not going to be contacted.

I work for one of the projects affected and know that they did not contact us in this case. If he had, we would have happily fixed the issue within a day or two. Instead our users are being put on the line as dumb script kiddies try out their new exploit while we finish up the bug fix.

Obviously you only write code with 0 bugs in it. Every software release from everywhere has bugs in it, it's life. This actually turned out to be a component that we use and not our code directly.

I didn't get fired or in trouble for this. However, it does impact users of our software that rely on our software and want a patch to this bug before every single script kiddie out there is now using this exploit in their l33t hax0r toolbox. I'm sure we'll have a fix out for it shortly, but it still doesn't help our users to be punished for something a vendor they aren't even using did at some point to make these people annoyed.

The problem is that they are not contacting vendors anymore at all since some of the previous times the vendor was slow or didn't react.

I work for one of the affected projects and can tell you that we did not get contacted by them via any of our normal, well publicized methods (email, phone calls, etc...).

I agree that if a vendor does not reply then it is totally okay to disclose it to force their hand. However, disclosing it immediately to the public and giving the vendor no chance to fix it (even a few days) is wrong imo.

Except he did not contact the vendors. He said in the past he has contacted some and they didn't fix it, so now he has given up on all vendors and does not disclose the information at all for any vendors.

I work for one of the affected projects and can tell you that we did not get contacted by them via any of our normal, well publicized methods (email, phone calls, etc...).

I agree that if a vendor does not reply then it is totally okay to disclose it to force their hand. However, disclosing it immediately to the public and giving the vendor no chance to fix it (even a few days) is wrong imo.

NY state does a tax on residents that purchase things from someone online with a NY affiliate. So if I live in NY (which I actually do) and buy an item from Amazon then I have to pay tax on it. This only affects the people of NY.

From what I understand the proposed NC law actually says that anything sold to anyone via an NC affiliate link would need to be taxed. So if someone lived in PA and bought something from Amazon, if they went through a NC affiliate link, it would be taxed by NC. This is not only taxing those items purchased by NC residents, but also people in other locations.

To make matters worse, if I lived in NY and then bought something via an NC affiliate, it would be taxed by both NY and NC.

This is why I suspect that Amazon cutoff the NC affiliates but not the NY ones.

MySQL Cluster will only write to the disk in an asynchronous manner. The disk is only needed if there is a total cluster failure (ie. all machines go down at once)

However the data is written synchronously to more than a single node. So when you insert data, it is inserted into two places (or more, it is configurable) at the same time. That way even if one server goes down, you will still query from the other place.

The result of this, is that it still will scale linearly for writes as well. Keep in mind the data is also partitioned, so each node only keeps a piece of the data present in it.

Um.. the reason you would store the number that way is easy. And.. it's not "storing a number backwards" it's little endian byte order, and it does make perfect sense.

The reason they are stored that way is because the current processors are based on the original 8-bit processors plus the 16-bit addons. Now you get a 32-bit processor that needs to be backwards compatible.

They are stored in memory in reverse byte order, and processed in the same order.
Say you have a 32 bit unsigned int variable at memory location 0x100 (for simplicity) that means it's taking 4 bytes, 0x100->0x103. So, if you store a number like 45 (0x0000002D) in it, it would go into memory as 2D 00 00 00. If you want to copy that to a byte, you copy memory location 0x100, and you've got it. In big endian byte order, it'd be stored as 00 00 00 2D (natural form) but if you want to store it in a byte, you have to grab memory location 0x100 + sizeof(unsigned long int) - sizeof(byte) so you'd get location 0x103, which is where that single byte is stored.

Does all that make sense? You may think something like "oh, storing a number backwards is evil and makes no sense", but if you are programming in assembler, it does make ALOT of sense, and you're very glad that the processor does it for you.

Just my 2 cents.

Jeremy