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).
I think it is quite reasonable to assume that half of the registered users is not using the site at all - maybe more - people lose interest, sign up for a one-time must see page, whatever. And unused accounts are not deleted of course. I am one of the less active users; I have an account and spend maybe five minutes a week on Facebook, if that much.
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.
If you don't want to care about table types, then they don't have to. You can set the default table type to whatever you want. So if you set it to InnoDB, then they will always have InnoDB tables unless they override it.
Also one would argue that people already do know about physical storage, that the golden rule of relation theory is already broken. Specifying things such as Indexes and column types already are breaking that golden rule. Why do they exist then? Because of physical limitations that don't exist in pure relational theory. If you can get better performance by adding an index, will you do so?
It is the same sort of thing if features can be turned off in a database. You have to know if they are on or not before you can use them, the same thing applies in this case.
Also worth noting that afaik, none of the databases you listed there have autonomous transactions.
It will rollback the InnoDB parts, without being able to rollback the MyISAM part. However it will give you a big error saying something like: mysql> rollback;
ERROR 1196: Warning: Some non-transactional changed tables couldn't be
rolled back
I don't know nor have I ever met anyone that has done this by accident (except during development). I do know some that do it on purpose in production though, such as using MyISAM for auditing information, which should always be there, even if a transaction fails.
It does Predicate Locking, exactly what is required in order to get true Serializability. Basically that is the best way in order to get transactions to truly be serialzable. There are other ways as well (table level locks, etc...) which also work, but allow less performance.
Predicate locking is only required in serializable. The more isolation you get, the more about of locking you will incur. That is what is assumed when you ask for the higher level of isolation. If you require true serializable behavior, then you are willing to accept that. If you don't need it, then you can use a lower isolation level. I believe that SQL Server and DB2 also use Predicate locking AFAIK when in serializable.
InnoDB takes a snapshot in time with REPEATABLE READ (and doesn't lock anything to do so). That means you can not get any one elses data injected while you are inside your transaction, which means you get a snapshot of only completed transactions. Here is a link where the creator of InnoDB talks about using mysqldump.
It sounds like PostgreSQL's SERIALIZABLE is very similar to InnoDB's REPEATABLE READ setting. It might be because PostgreSQL isn't really serializable in the mathmatical sense while InnoDB is. I'm not that familar with PostgreSQL's internals to know if it is similar to InnoDB's REPEATABLE READ level.
No, InnoDB is multiversioning, similar to Oracle and PostgreSQL. That means that it uses non-locking reads, assuming you are running in the default isolation level of REPEATABLE READ.
The reason this is possible is due to the fact that whenever anyone goes to write a row, it creates an entire copy of the affected row, where the old transaction sees the old copy of the row while the new transactions will see the new copy.
Keep in mind this can change if you set a different isolation level. For example SERIALIZABLE runs in the highest isolation level, so it needs to set more locks than the other levels. There is more info available here and here if you want to read more.
You actually can take online backups of InnoDB without buying the InnoDB Hot Backup tool. The non-free tool allows you to take online *binary* backups, but if you want to take an online data backup you can do so using mysqldump with the --single-transaction method.
This will work basically identical to how you take the online backup with pg_dump. It takes a snapshot in time using the normal transaction isolation level semantics and dumps it into a plain text file.
Keep in mind that dumping the data is slower than doing a binary backup (also for restore) but that is true for any database. If you just need online backup capabilities, it is built in. If you need it to be faster than you can choose to buy the online binary backup feature.
Maybe I phrased that wrong.
The EXPAT parser has come standard built into PHP since 4.0 beta 3. You have to willingly disable it at compile time with the --disable-xml flag.
The XML PHP library again will be installed automagically as part of the base PEAR install, unless you say otherwise.
The only thing you are required to install from my above post was the XML_RSS library, everything else comes STANDARD with PHP unless you compile without them.
Slashdot Mirror
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).
I think it is quite reasonable to assume that half of the registered users is not using the site at all - maybe more - people lose interest, sign up for a one-time must see page, whatever. And unused accounts are not deleted of course. I am one of the less active users; I have an account and spend maybe five minutes a week on Facebook, if that much.
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.
If you don't want to care about table types, then they don't have to. You can set the default table type to whatever you want. So if you set it to InnoDB, then they will always have InnoDB tables unless they override it.
Also one would argue that people already do know about physical storage, that the golden rule of relation theory is already broken. Specifying things such as Indexes and column types already are breaking that golden rule. Why do they exist then? Because of physical limitations that don't exist in pure relational theory. If you can get better performance by adding an index, will you do so?
It is the same sort of thing if features can be turned off in a database. You have to know if they are on or not before you can use them, the same thing applies in this case.
Also worth noting that afaik, none of the databases you listed there have autonomous transactions.
It will rollback the InnoDB parts, without being able to rollback the MyISAM part. However it will give you a big error saying something like:
mysql> rollback;
ERROR 1196: Warning: Some non-transactional changed tables couldn't be rolled back
I don't know nor have I ever met anyone that has done this by accident (except during development). I do know some that do it on purpose in production though, such as using MyISAM for auditing information, which should always be there, even if a transaction fails.
It is worth noting that MySQL with InnoDB has supported SAVEPOINT's now for a few versions. [code]http://www.mysql.com/doc/en/Savepoints.html[ /code]
It does Predicate Locking, exactly what is required in order to get true Serializability. Basically that is the best way in order to get transactions to truly be serialzable. There are other ways as well (table level locks, etc...) which also work, but allow less performance.
Predicate locking is only required in serializable. The more isolation you get, the more about of locking you will incur. That is what is assumed when you ask for the higher level of isolation. If you require true serializable behavior, then you are willing to accept that. If you don't need it, then you can use a lower isolation level. I believe that SQL Server and DB2 also use Predicate locking AFAIK when in serializable.
Yes.
InnoDB takes a snapshot in time with REPEATABLE READ (and doesn't lock anything to do so). That means you can not get any one elses data injected while you are inside your transaction, which means you get a snapshot of only completed transactions. Here is a link where the creator of InnoDB talks about using mysqldump.
It sounds like PostgreSQL's SERIALIZABLE is very similar to InnoDB's REPEATABLE READ setting. It might be because PostgreSQL isn't really serializable in the mathmatical sense while InnoDB is. I'm not that familar with PostgreSQL's internals to know if it is similar to InnoDB's REPEATABLE READ level.
No, InnoDB is multiversioning, similar to Oracle and PostgreSQL. That means that it uses non-locking reads, assuming you are running in the default isolation level of REPEATABLE READ.
The reason this is possible is due to the fact that whenever anyone goes to write a row, it creates an entire copy of the affected row, where the old transaction sees the old copy of the row while the new transactions will see the new copy.
Keep in mind this can change if you set a different isolation level. For example SERIALIZABLE runs in the highest isolation level, so it needs to set more locks than the other levels. There is more info available here and here if you want to read more.
You actually can take online backups of InnoDB without buying the InnoDB Hot Backup tool. The non-free tool allows you to take online *binary* backups, but if you want to take an online data backup you can do so using mysqldump with the --single-transaction method. This will work basically identical to how you take the online backup with pg_dump. It takes a snapshot in time using the normal transaction isolation level semantics and dumps it into a plain text file. Keep in mind that dumping the data is slower than doing a binary backup (also for restore) but that is true for any database. If you just need online backup capabilities, it is built in. If you need it to be faster than you can choose to buy the online binary backup feature.
Maybe I phrased that wrong.
The EXPAT parser has come standard built into PHP since 4.0 beta 3. You have to willingly disable it at compile time with the --disable-xml flag.
The XML PHP library again will be installed automagically as part of the base PEAR install, unless you say otherwise.
The only thing you are required to install from my above post was the XML_RSS library, everything else comes STANDARD with PHP unless you compile without them.
PHP has built in support for expat XML parser The parser has come with PHP since PHP 4.0 Beta 4.
There also is a nice wrapper called XML_parser in PEAR. That package is installed by default in PHP 4 I believe.
If you are going to deal with RSS and RDF stuff, then I definately recommend you check out the PEAR XML_RSS package
I see nothing lacking with PHPs XML support.