Sure, because a mere fact that someone was raided by FBI is a proof that he's a criminal. And let's trust some unnamed Commentary who claims that the raided person is linked to a certain (yet unnamed) branches of Mafia. Not to be prudent, but many former US presidents were accused of Mafia links and relations too.
Not true. Have you actually checked the code, or do you just repeat the nonsense mentioned on many sites?
I haven't done a thorough analysis of the code / traffic so far, but from what I've seen so far the key is generated on the client-side using this Javascript, namely SJCL (Stanford Javascript Crypto Library). For example this is the keygen: https://eu.static.mega.co.nz/keygen_0.js, this is the RSA implementation https://eu.static.mega.co.nz/rsa_0.js and so on. Once the key is generated on client, the private key is encrypted with the user's password (which is also kept on client-side only), and this (public and encrypted private key) is sent to Mega server. On the next login the server sends the encrypted key (after some initial handshake, described in the developer docs) and the key is decrypted on the client-side again.
Please, explain to me how the server knows both my keys, how can they decrypt the data?
Obviously, there could be a malware, or they could send the password to the server, but let's suppose that's not the case.
That seems rather like a spamfilter-related issue. I had the same problem (not receiving the activation e-mail on my primary e-mail), so I tried a different e-mail and the link arrived almost immediately.
Not sure which Oracle books you mean - I've read e.g. "PL/SQL Programming" (ISBN 978-0072230666) and "Expert Oracle PL/SQL" (ISBN 978-0072261943) and probably some more when preparing for OCP exams. And I'd definitely recommend ISBN 978-0596514464 instead of the first one. But yeah, it's a matter of opinion.
But you're right - there are no "PostgreSQL for MySQL people" guides. The problem is that almost no one is able to write it. The people who are switching from MySQL to PostgreSQL don't have the knowledge and experienced people using PostgreSQL don't know MySQL that much (at least that's my impression).
I mean - PostgreSQL does have 32 bit transactions IDs and a well designed process to prevent wraparound.
Oracle has 48bit transaction IDs, a number of bugs that speed up transaction ID growth, a feature that "synchronizes" transaction IDs through the whole cluster (thus the IDs are growing according to the busiest of the instances) and a soft SCN limit (16k * seconds since 1988) that when reached, bad things happen. I'm not saying this happens every other day, but with new shiny HW the soft SCN limit is rather easily reachable.
So while PostgreSQL has this sorted out long time ago in a quite reasonable way, Oracle issued / is issuing patches that are rather workarounds than patches. So saying "Until they fix the TX number issue..." sounds a bit strange to me.
What's wrong with third-party stuff? I mean, looking bad it was silly to expect this to happen with replication (third-party replication solutions, not included in the core), but with the management tools this should not be a problem - there are already tools like repmgr and more to come. The problem with in-core tools is that they hard-code a single way to do things the release cycle is tightly bound to the PostgreSQL itself and it's a significant effort for the whole community.
Regarding the replication - it's still a relatively new feature (although two years is a long time), so it has some rough edges, but I wouldn't call it kludgey at all. It's very nicely thought-out and crafted feature. Once you get an idea of how it works / how to set it up, it's fairly simple to do that again and even write a bunch of simple scripts to manage it.
And yeah, there are many features we'd like to see in PostgreSQL, but the community simply has a limited manpower and it's using it to satisfy the main needs of it's current users. It's not that the community strives to beat all the other databases - the goal of the community is to provide useful features for it's users.
Well, recommending a PL/SQL book as a source for learning SQL is a bit silly IMHO. Moreover, I find the books from Oracle rather bad - there are better sources to learn PL/SQL (e.g. the one from Feuerstein is a much better book).
And in fact there's a great book about administering PostgreSQL from Hannu Krosing - it's called "PostgreSQL 9 Admin Cookbook" [http://www.packtpub.com/postgresql-9-admin-cookbook/book]. It's a great set of recipes for admins for common tasks, not an exhaustive documentation (that's what http://www.postgresql.org/docs/9.1/interactive/index.html is for), but if you want to learn how real pros admin the database, this is the right choice. And yes, I'd recommend it to newbies coming from MySQL.
It might seem that the PostgreSQL community considered MySQL to be a toy database in the past, but it definitely was not a generally shared view. And this definitely changed recently - there's no reason not to join the community mailing lists / IRC channel and start a post with "I'm using a MySQL right now and I don't understand why PostgreSQL does SOMETHING."
Most of the shared memory is usually reserved for shared buffers, i.e. cached blocks of data files - this is something like a filesystem cache (and yes, some data may be cached twice) with the additional infrastructure for shared access to these blocks (especially for write), and so on. But there's more that needs to be shared - various locks / semaphores etc. info on connections, cluster-wide caches (not directly files) etc.
I'm not saying some of this can't be done using a page cache in Linux or something, but relying on that would make the whole database much more difficult to port to various OS (right now it has almost zero knowledge of the file system / cache beneath it). So it has pros and cons, and the pros of using shared memory outweight the cons.
Yeah, sorry for that typo. I admit I was a bit drunk when writing that post and moreover - English is not my mother tongue. Try to write something in Czech and I'll have plenty of opportunities to grammar-nazi you;-)
That is not the point - you'll loose data whenever there's a cache without a battery backup involved. The problem is that with some drives (good ones) you'll get at least a consistent filesystem (or easy to fix thanks to the journal), because the operations may be ordered somehow. The bad drives don't respect the ordering, making the corruption much more serious and potentially unfixable.
I generally do agree that the internet is full of blogs and sites that just claim whatever they want to be true, without reliable proofs. The best source I've found so far are the reports presented by the "Director of the Administrative Office of the United States Courts" on "Applications for Delayed-Notice Search Warrants and Extensions". You can find that on ACLU site and on many other sites. For example by comparing the stats for 2008 and 2009, it's quite clear that most of the cases has nothing to do with terrorism (less than 2% of reports/warrants is in this category) and most of that comes from 64% in 2008, 76% in 2009 (not sure about 2010) are about "drugs". Sure, fighting drugs and other crimes is important, but is it necessary to break the way the law was built? I mean for example the NLS, requesting information and forbidding to speak about that. And those letters are not covered by the report - the only number I found is that between 2003 and 2006 there were almost 175.000 of them.
I want to make clear that I'm not a US citizen and I don't live there - but we do have very similar issues right here, in Europe. The police got used to solve even the simplest crimes by eavesdropping the phone (until the court forbid them to do so last year), which is very similar to the patriot act - no serious reviews of the warrants, etc.
And lot of that FUD is true. There are many reports on the net, describing how the Patriot Act is misused even in cases that are not related to terorism. It's much easier that regular subpoenas etc. so they misuse it.
What? How is a *law* imposed on other countries comparable to a *requirement* imposed on businesses willing to operate on the US soil? The requirement is still a bit weird (as they will impose US rules to businesses in other countries), but it's your decision to go to US. The law is going to be imposed on businesses that have nothing to do with the US (except that their website might be reachable).
Forcing businesses outside US to follow US laws is like prohibiting people in China to wear red caps.
Exactly. The belief that the Megaupload case (arrest of those who ran it) somehow proves that USA can ask (and get automatically) whatever they want is just crazy. First, AFAIK the case has nothing to do with Patriot Act, mentioned in the case. Second, a US government by itself can't improse laws on businesses in different countries, unless those governments are run by US citizens (to some extent). All the other rules have to be somehow negotiated (international laws).
They can ask for whatever they want, the other party is free to tell them to... go away. I'm not saying it's that simple (the are powerful lobyist groups that are pushing the governments to cooperate with US (as for example motion-picture associations in the megaupload case).
One option to prevent this bullying is to move the infrastructure to countries that compete with the US so they probably won't be too keen to cooperate with the US. I mean Russia, China,... Yes, I'm fully aware there are other risks connected to these countries.
Yes, but that's true for both considered options (MSSQL and PostgreSQL). I have no clue how well the app is designed / written - with reasonable abstraction, the amount of code that needs to be rewritten should be minimal. Also, chosing a database with good spatial features may save a lot of custom code.
First of all, it's not your developers who should do this decision. Yes, you should ask for their opinion but if they're the "we know MSSQL and we're not willing to see other options therefore everything else is worse" type then they'll choose MSSQL no matter what. So do a cost-benefit analysis, as already recommended by wasabii.
Before giving any specific recommendations, I have to mention that I'm a PostgreSQL-guy. I do like how mature and reliable the database is, how the community works, how fast the occasional bugs are fixed, etc. Therefore I'd recommend you to give PostGIS a try - AFAIK the spatial functionality is infinitely better than in MySQL, quite comparable to MSSQL. There is a nice comparison matrix of features at http://www.bostongis.com/PrinterFriendly.aspx?content_name=sqlserver2008_postgis_mysql_compare but it's very old - it may give you an idea how the products compare. You can probably get more details on the PostGIS mailing list.
You should really decide whether you want to go with an open-source solution or not, how important the benefits are for you etc.
There's a saying about stupid questions and answers, but never mind... Your answer is based on several assumptions:
You're right that custom code is usually more expensive than already available boxed solutions, under the assumption that the generic solution implements only the needed code and does not need to be modified. If the generic solution implements much wider range of functionality than you actually need, the custom code may be actually much cheaper. And if you need/want to change the internals, it's going to be very expensive (outweighing the prior savings) or even impossible. Plus you usually have zero influence on future of the product.
I really don't see how the choice of MSSQL (or any other database) eliminates the need for proper testing...
Sure you do lose lot of things. What about bugfixes, for example?
Yes, you can use the sources from the GPL-times, the businesses really don't want to do that on their own. And forking a project successfully really is not that simple as it loks like. There are forks of MySQL, and maybe one of them will be a success in the future (I'd be glad to see that), but which one? And what are the guarantees?
OK, I haven't heard about this term before. Shame on me...
In that case I have to agree with the OP - the open core does not work. More precisely, it does not work for the users because they don't get the freedoms, just s nicely wrapped lock-in. I think Simon Phipps explains that quite nicely (see the link on the wiki page).
I'm not that sure if it works for Oracle, that's a different question. Maybe they'll achieve their goals, whatever they are.
That's not true. MySQL always had dual licensing - GPL and MySQL License. MySQL always held all the rights to the source code. This is basically the reason why MySQL never formed a truly open developer community, as that would make this 'license drop' impossible (or much more difficult). Now Oracle owns MySQL, thus all the rights.
They may drop GPL licensing any time they want (OK, there were some promises to EU) and provide further versions only under their own license. Will that happen tomorrow? I don't think so. Will that happen next year? I don't know? And I doubt Oracle has an exact plan what to do with MySQL.
Slashdot Mirror
Sure, because a mere fact that someone was raided by FBI is a proof that he's a criminal. And let's trust some unnamed Commentary who claims that the raided person is linked to a certain (yet unnamed) branches of Mafia. Not to be prudent, but many former US presidents were accused of Mafia links and relations too.
Not true. Have you actually checked the code, or do you just repeat the nonsense mentioned on many sites?
I haven't done a thorough analysis of the code / traffic so far, but from what I've seen so far the key is generated on the client-side using this Javascript, namely SJCL (Stanford Javascript Crypto Library). For example this is the keygen: https://eu.static.mega.co.nz/keygen_0.js, this is the RSA implementation https://eu.static.mega.co.nz/rsa_0.js and so on. Once the key is generated on client, the private key is encrypted with the user's password (which is also kept on client-side only), and this (public and encrypted private key) is sent to Mega server. On the next login the server sends the encrypted key (after some initial handshake, described in the developer docs) and the key is decrypted on the client-side again.
Please, explain to me how the server knows both my keys, how can they decrypt the data?
Obviously, there could be a malware, or they could send the password to the server, but let's suppose that's not the case.
That seems rather like a spamfilter-related issue. I had the same problem (not receiving the activation e-mail on my primary e-mail), so I tried a different e-mail and the link arrived almost immediately.
Yeah, we want Borg Ballmer.
Not sure which Oracle books you mean - I've read e.g. "PL/SQL Programming" (ISBN 978-0072230666) and "Expert Oracle PL/SQL" (ISBN 978-0072261943) and probably some more when preparing for OCP exams. And I'd definitely recommend ISBN 978-0596514464 instead of the first one. But yeah, it's a matter of opinion.
But you're right - there are no "PostgreSQL for MySQL people" guides. The problem is that almost no one is able to write it. The people who are switching from MySQL to PostgreSQL don't have the knowledge and experienced people using PostgreSQL don't know MySQL that much (at least that's my impression).
So you're calling yourself an Oracle professional and you're not aware of this: http://www.infoworld.com/d/security/fundamental-oracle-flaw-revealed-184163-0 ?
I mean - PostgreSQL does have 32 bit transactions IDs and a well designed process to prevent wraparound.
Oracle has 48bit transaction IDs, a number of bugs that speed up transaction ID growth, a feature that "synchronizes" transaction IDs through the whole cluster (thus the IDs are growing according to the busiest of the instances) and a soft SCN limit (16k * seconds since 1988) that when reached, bad things happen. I'm not saying this happens every other day, but with new shiny HW the soft SCN limit is rather easily reachable.
So while PostgreSQL has this sorted out long time ago in a quite reasonable way, Oracle issued / is issuing patches that are rather workarounds than patches. So saying "Until they fix the TX number issue ..." sounds a bit strange to me.
Damn, this was supposed to be a response for the parent flamebait ...
Could you please compare Ferrari F1 and Liebherr T1-272 minin truck [e.g. http://www.flickr.com/photos/doncampbellmodels/3434490464/%5D? Not possible, right? Different products for different requirements.
What's wrong with third-party stuff? I mean, looking bad it was silly to expect this to happen with replication (third-party replication solutions, not included in the core), but with the management tools this should not be a problem - there are already tools like repmgr and more to come. The problem with in-core tools is that they hard-code a single way to do things the release cycle is tightly bound to the PostgreSQL itself and it's a significant effort for the whole community.
Regarding the replication - it's still a relatively new feature (although two years is a long time), so it has some rough edges, but I wouldn't call it kludgey at all. It's very nicely thought-out and crafted feature. Once you get an idea of how it works / how to set it up, it's fairly simple to do that again and even write a bunch of simple scripts to manage it.
And yeah, there are many features we'd like to see in PostgreSQL, but the community simply has a limited manpower and it's using it to satisfy the main needs of it's current users. It's not that the community strives to beat all the other databases - the goal of the community is to provide useful features for it's users.
Well, recommending a PL/SQL book as a source for learning SQL is a bit silly IMHO. Moreover, I find the books from Oracle rather bad - there are better sources to learn PL/SQL (e.g. the one from Feuerstein is a much better book).
And in fact there's a great book about administering PostgreSQL from Hannu Krosing - it's called "PostgreSQL 9 Admin Cookbook" [http://www.packtpub.com/postgresql-9-admin-cookbook/book]. It's a great set of recipes for admins for common tasks, not an exhaustive documentation (that's what http://www.postgresql.org/docs/9.1/interactive/index.html is for), but if you want to learn how real pros admin the database, this is the right choice. And yes, I'd recommend it to newbies coming from MySQL.
It might seem that the PostgreSQL community considered MySQL to be a toy database in the past, but it definitely was not a generally shared view. And this definitely changed recently - there's no reason not to join the community mailing lists / IRC channel and start a post with "I'm using a MySQL right now and I don't understand why PostgreSQL does SOMETHING."
No, I'm not aware of such thing ("PostgreSQL for MySQL people" style guide).
The best thing you can do is give it a ride - install it, use http://www.postgresql.org/docs/9.1/interactive/admin.html to do the setup etc.
Basically all you need to do to install and start the PostgreSQL from source code is this (at least on Linux):
$ cd postgresql-9.1.5 ./configure --prefix=/path-to-install /database-directory init ... fiddle with the config at /database-directory/postgresql.conf /database-directory -l /database-directory/postgresql.log start
$
$ make install
$ export PATH=/path-to-install/bin:$PATH
$ pg_ctl -D
$ pg_ctl -D
and then
$ createdb testdb
$ psql testdb
and you're in. If you're installing that from a package (e.g. RPM in RedHat), it might work a bit differently - depends on the packager.
Anyway, use the project mailing lists and IRC channel - there's always someone ready to help / answer novice or complex questions etc.
Because it's not just caching ...
Most of the shared memory is usually reserved for shared buffers, i.e. cached blocks of data files - this is something like a filesystem cache (and yes, some data may be cached twice) with the additional infrastructure for shared access to these blocks (especially for write), and so on. But there's more that needs to be shared - various locks / semaphores etc. info on connections, cluster-wide caches (not directly files) etc.
I'm not saying some of this can't be done using a page cache in Linux or something, but relying on that would make the whole database much more difficult to port to various OS (right now it has almost zero knowledge of the file system / cache beneath it). So it has pros and cons, and the pros of using shared memory outweight the cons.
Yeah, sorry for that typo. I admit I was a bit drunk when writing that post and moreover - English is not my mother tongue. Try to write something in Czech and I'll have plenty of opportunities to grammar-nazi you ;-)
That is not the point - you'll loose data whenever there's a cache without a battery backup involved. The problem is that with some drives (good ones) you'll get at least a consistent filesystem (or easy to fix thanks to the journal), because the operations may be ordered somehow. The bad drives don't respect the ordering, making the corruption much more serious and potentially unfixable.
I generally do agree that the internet is full of blogs and sites that just claim whatever they want to be true, without reliable proofs. The best source I've found so far are the reports presented by the "Director of the Administrative Office of the United States Courts" on "Applications for Delayed-Notice Search Warrants and Extensions". You can find that on ACLU site and on many other sites. For example by comparing the stats for 2008 and 2009, it's quite clear that most of the cases has nothing to do with terrorism (less than 2% of reports/warrants is in this category) and most of that comes from 64% in 2008, 76% in 2009 (not sure about 2010) are about "drugs". Sure, fighting drugs and other crimes is important, but is it necessary to break the way the law was built? I mean for example the NLS, requesting information and forbidding to speak about that. And those letters are not covered by the report - the only number I found is that between 2003 and 2006 there were almost 175.000 of them.
I want to make clear that I'm not a US citizen and I don't live there - but we do have very similar issues right here, in Europe. The police got used to solve even the simplest crimes by eavesdropping the phone (until the court forbid them to do so last year), which is very similar to the patriot act - no serious reviews of the warrants, etc.
And lot of that FUD is true. There are many reports on the net, describing how the Patriot Act is misused even in cases that are not related to terorism. It's much easier that regular subpoenas etc. so they misuse it.
What? How is a *law* imposed on other countries comparable to a *requirement* imposed on businesses willing to operate on the US soil? The requirement is still a bit weird (as they will impose US rules to businesses in other countries), but it's your decision to go to US. The law is going to be imposed on businesses that have nothing to do with the US (except that their website might be reachable).
Forcing businesses outside US to follow US laws is like prohibiting people in China to wear red caps.
Exactly. The belief that the Megaupload case (arrest of those who ran it) somehow proves that USA can ask (and get automatically) whatever they want is just crazy. First, AFAIK the case has nothing to do with Patriot Act, mentioned in the case. Second, a US government by itself can't improse laws on businesses in different countries, unless those governments are run by US citizens (to some extent). All the other rules have to be somehow negotiated (international laws).
They can ask for whatever they want, the other party is free to tell them to ... go away. I'm not saying it's that simple (the are powerful lobyist groups that are pushing the governments to cooperate with US (as for example motion-picture associations in the megaupload case).
One option to prevent this bullying is to move the infrastructure to countries that compete with the US so they probably won't be too keen to cooperate with the US. I mean Russia, China, ... Yes, I'm fully aware there are other risks connected to these countries.
Yes, but that's true for both considered options (MSSQL and PostgreSQL). I have no clue how well the app is designed / written - with reasonable abstraction, the amount of code that needs to be rewritten should be minimal. Also, chosing a database with good spatial features may save a lot of custom code.
First of all, it's not your developers who should do this decision. Yes, you should ask for their opinion but if they're the "we know MSSQL and we're not willing to see other options therefore everything else is worse" type then they'll choose MSSQL no matter what. So do a cost-benefit analysis, as already recommended by wasabii.
Before giving any specific recommendations, I have to mention that I'm a PostgreSQL-guy. I do like how mature and reliable the database is, how the community works, how fast the occasional bugs are fixed, etc. Therefore I'd recommend you to give PostGIS a try - AFAIK the spatial functionality is infinitely better than in MySQL, quite comparable to MSSQL. There is a nice comparison matrix of features at http://www.bostongis.com/PrinterFriendly.aspx?content_name=sqlserver2008_postgis_mysql_compare but it's very old - it may give you an idea how the products compare. You can probably get more details on the PostGIS mailing list.
You should really decide whether you want to go with an open-source solution or not, how important the benefits are for you etc.
Better than what? And why is the XML stuff important (the original poster did not mention that at all)?
There's a saying about stupid questions and answers, but never mind ... Your answer is based on several assumptions:
You're right that custom code is usually more expensive than already available boxed solutions, under the assumption that the generic solution implements only the needed code and does not need to be modified. If the generic solution implements much wider range of functionality than you actually need, the custom code may be actually much cheaper. And if you need/want to change the internals, it's going to be very expensive (outweighing the prior savings) or even impossible. Plus you usually have zero influence on future of the product.
I really don't see how the choice of MSSQL (or any other database) eliminates the need for proper testing ...
Sure you do lose lot of things. What about bugfixes, for example?
Yes, you can use the sources from the GPL-times, the businesses really don't want to do that on their own. And forking a project successfully really is not that simple as it loks like. There are forks of MySQL, and maybe one of them will be a success in the future (I'd be glad to see that), but which one? And what are the guarantees?
OK, I haven't heard about this term before. Shame on me ...
In that case I have to agree with the OP - the open core does not work. More precisely, it does not work for the users because they don't get the freedoms, just s nicely wrapped lock-in. I think Simon Phipps explains that quite nicely (see the link on the wiki page).
I'm not that sure if it works for Oracle, that's a different question. Maybe they'll achieve their goals, whatever they are.
That's not true. MySQL always had dual licensing - GPL and MySQL License. MySQL always held all the rights to the source code. This is basically the reason why MySQL never formed a truly open developer community, as that would make this 'license drop' impossible (or much more difficult). Now Oracle owns MySQL, thus all the rights.
They may drop GPL licensing any time they want (OK, there were some promises to EU) and provide further versions only under their own license. Will that happen tomorrow? I don't think so. Will that happen next year? I don't know? And I doubt Oracle has an exact plan what to do with MySQL.